这篇文章最初于 2014 年在 WordPress 中发布，是一个缓慢的 CMS - 2014
我不止一次地陷入这样的争论：WordPress 慢吗？好吧，当附加到 WordPress 的人的唯一反应是有很多访问量的网站拥有它并且它们的性能是最佳的时，这并没有太大的争论。他们自己似乎忘记了，如果在功能强大的计算机上“运行”，即使冒泡排序算法对于过大的样本也表现良好。然而，如果我们看看它的计算复杂度，这并不意味着它一定是一个有效的算法（事实上，它不是）。同样的事情也发生在 WordPress 上。对于相同数量的信息，它需要比其他 CMS 更强大的托管。不仅如此，正如我们将看到的，无论它是否有大量信息，它都已经是一个缓慢的 CMS。
这并不意味着 WordPress 不好。事实并非如此。就像汽车一样，速度并不是一切。同样的事情也发生在 CMS 领域。事实上，我的很大一部分网络项目都是用它来完成的。然而，每个项目都是不同的，因此，你必须知道如何用你的头脑而不是执着来适当地选择最好的工具。
由于我是一名技术人员，我的论点将基于技术方面。特别是当我了解到 WordPress 由于其设计而速度缓慢时。我邀请所有不同意的人给我留言并说出他们的理由。
一切都在一张桌子上。
当我们为 Web 项目创建数据库模式时，会出现一个问题：是追求实用还是追求高效。就 WordPress 而言，他们选择了实用性，并将帖子、自定义帖子、资源和版本分组在同一个表中：wp_posts。这个动作的优点是简化了代码和搜索（尽管这是 WordPress 所缺少的另一件事，我们将在另一篇文章中看到），但另一方面它大大降低了 WordPress 的效率。一些理解的例子：
如果我们有 500 个帖子，每个帖子都有 4 个不同的评论（当前的一个和另外三个），就好像我们正在处理 2,000 个帖子。
如果我们在 Woocommerce 上有 500 种产品，并且每一种都有一张特色图片和四个作为该产品的图库，就好像我们的 CMS 必须处理 3,000 种产品。
如果我们有一个 35 个页面的小网站，上面有大约 35 个菜单项，带有外部或内部链接。我们的内容管理器将像我们有 70 个页面一样工作。因为每个菜单项都被视为我们 CMS 中的一个条目或一个页面。在这个例子中，这并不多，但我这样做是为了让您可以看到另一个影响因素。
如果您有 500 种产品和四种语言，那么您的 WordPress 就好像它适用于 2,000 种产品。
现在让我们看一个真实的例子作为总结：如果您有一个包含 500 个产品的网站，并且每个产品都有一个特色图片、四个产品图库图片和一个包含每个产品技术信息的 pdf 。此外，该网站还有一个博客，其中有 200 个条目，每个条目都有相应的特色图像。另外，如果您的网站支持三种语言，并且每个帖子只有两条评论。每次 WordPress 对数据库发起查询时，它都必须在 5,500 多个元素中进行搜索。我鄙视其他的东西，比如菜单项、页面和自定义帖子。温馨提示：
将评论数量限制为两个或完全禁用评论：
//Limita las revisiones a dos:
define( 'WP\_POST\_REVISIONS', 2 );
//Desactiva totalmente las revisiones:
//define( 'WP\_POST\_REVISIONS', false );
登录后复制
- 不时删除所有修订。您可以通过启动以下 sql 查询来完成此操作：
DELETE a,b,c FROM wp_posts a
LEFT JOIN wp\_term\_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp\_postmeta c ON (a.ID = c.post\_id)
WHERE a.post_type = 'revision'
登录后复制
对网站上的图片保持严肃态度。另外，请勿将您不会使用的图像添加到您的 CMS。
如果不是必需的，请避免使用过多的菜单。删除您不打算使用的菜单项。
如果您因为客户的坚持而别无选择，除了在中型或大型项目中使用 WordPress 之外，请尝试创建辅助表，从而尽可能减轻 wp_posts 的负载
你的 WordPress 患有老年痴呆症
WordPress 不惜一切代价寻求灵活性，甚至不惜牺牲速度。也许，因为一开始它只是一个博客系统，在这种情况下，如此大的灵活性不会造成如此大的损害。然而，当我们开始将它用作 CMS 时，灵活性导致的性能问题就开始出现了。
Déjame decirte una mala noticia: tu gestor de contenidos tiene alzheimer. Se le olvida todo de una petición a otra. Tendrás que repetirle en cada una de ellas los customs posts, los sidebars, o los menús que vas a usar. No te queda otra porque a él se le olvida. Es por ello, que si quieres añadir una entrada al menú del panel, por ejemplo, se lo tendrás que decir cada vez que se vaya a mostrar. Sí, da una enorme flexibilidad pero obliga a PHP y al CMS a procesar lo mismo una vez y otra vez, dando lugar a una perdida de eficiencia. Lo mismo le pasa a los plugins y es por ello que muchos plugins pueden ralentizar sobremanera tu sitio web. No por el sistema de plugins en sí ( que es magnifico como está pensado y programado ), sino por la obligación de los plugins de decir lo mismo una y otra vez y, por tanto, la necesidad de WordPress de recorrerlos completamente en cada petición.
Un CMS enfocado al rendimiento lo hubiera hecho de otra manera. Por ejemplo, haciendo que durante la activación del tema éste dijera que sidebars, custom posts o cualquier otro elemento necesita. WordPress lo registraría y se ajustaría adecuadamente de manera interna. Y lo mismo para los plugins. Pero, como digo anteriormente, un proceder así restaría mucha flexibilidad al CMS, algo que no les interesa.
Consejos:
Limita el número de plugins
Escoge temas minimalistas o que sólo tengan lo que necesites
Te recomendarán que uses un plugin de caché, yo no. Úsalo sólo en el caso que tu sitio web vaya extremadamente lento y siempre con pinzas. Hablaré de ello en otra entrada (edit: ya está disponible: No uses plugins de caché con WordPress , aunque básicamente es porque cortarás todo el funcionamiento interno de WordPress basado en hooks. Es decir, forzarás a trabajar a WordPress de una manera, que como hemos visto, no es la que han decidido para él.
Todo siempre a tu disposición
WordPress, como casi todo el mundo sabe, empezó como un sistema de blogs que se basaba en otro sistema anterior. No estaba pensado para proyectos grandes es por eso que su diseño tendió a lo simple. No clases, sólo funciones. Como cualquier aspecto de diseño, eso no tiene que ser algo necesariamente malo ( sino que se lo digan a los que usan escritorios realizados con GTK ), a no ser que busques la flexibilidad. Entonces, es cuando empiezan los dolores de cabeza.
Si vienes del mundo PHP, seguramente te sorprendas que con WordPress no has tenido ni que hacer requires, ni includes ni usar namespace. Es algo sencillo de entender, el motivo es que WordPress siempre carga todo su arsenal de librerías. Sí, siempre, las uses o no. Si lo sumamos a que tiene alzheimer, uff. Líneas de código que se tienen que leer si o si en cada petición. Un pasote. Pero, claro, piensa que es por la flexibilidad. Puedes usar una función del core sin tener que hacer un include a un fichero que puede que el día de mañana tenga otro nombre o esté en otro path.
A partir de PHP 5.6 hay soporte completo de namespace de funciones. Quizás esa sea una solución para WordPress. Pero en ese caso tendrán que tomar la difícil decisión de crear incompatibilidad hacia atrás. No sé lo que harán.
Nada puedes hacer para mejorar esto, ya que es parte del diseño de WordPress. Tan sólo te queda hacer tu parte, es decir, que tu código no siga esa línea. Si te decides a hacerlo, aquí mis consejos:
- Crea funciones anónimas para los "actions" y que no sean más que un include a ficheros externos dónde tengas tu código. Así, si esa acción no llega nunca a lanzarse tampoco PHP tendrá que parsear todo el código. Ejemplo:
add\_action('admin\_init', function() {
include(\_\_DIR\_\_."/zonas/panel/init.php");
});
add\_action('admin\_menu', function() {
include(\_\_DIR\_\_."/zonas/panel/menu.php");
});
登录后复制
- Para widgets, shortcodes y filtros, usa clases con namespace. Además, que estás clases se instancien mediante autocarga.
//Recomendable usar mejor: spl\_autoload\_register()
function __autoload($classname) {
$file = str\_replace('', DIRECTORY\_SEPARATOR, $classname);
include_once(BASE_PATH.$file.'.php');
}
add_shortcode( 'block', array('misshortcodesBlock', 'load') );
//...mis otros shortcodes, filtros y widgets, ....
登录后复制
Como resumen, hemos visto que WordPress tiene como principios de diseño a la simplicidad y flexibilidad, pero de una forma que le resta eficiencia. Hay que pensar que ninguna herramienta de desarrollo es buena para todo. Si alguien te lo presenta así es porque te está engañando o te vende una navaja suiza que no sirve para nada. WordPress cojea en su velocidad, pero para sitios webs escaparates es algo que no hay que darle mayor importancia. Para sitios en los que el negocio es la web se debería de plantear otras alternativas. Lo mismo para sitios con bastante tráfico. Si aún así queremos WordPress por su facilidad de uso y flexibilidad hemos de saber que habremos de compensarlo con un buen alojamiento, mucho cuidado con la selección de plugins y un tema de calidad y ajustado a nuestras necesidades.
以上是WordPress 是一个缓慢的 CMS的详细内容。更多信息请关注PHP中文网其他相关文章！
