这篇文章最初于 2014 年在 wordpress is a slow 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 时，灵活性导致的性能问题就开始出现了。
让我告诉您一些坏消息：您的内容经理患有阿尔茨海默氏症。你会忘记从一个请求到另一个请求的所有事情。您必须在每个帖子中重复您要使用的自定义帖子、侧边栏或菜单。你别无选择，因为他忘记了。这就是为什么如果您想在面板菜单中添加一个条目，您就必须在每次显示它时都告诉它。是的，它提供了巨大的灵活性，但它迫使 php 和 cms 一遍又一遍地处理相同的事情，从而导致效率损失。插件也会发生同样的情况，这就是为什么许多插件会大大减慢您的网站速度。不是因为插件系统本身（它的设计和编程非常出色），而是因为插件有义务一遍又一遍地说同样的事情，因此，wordpress 需要完全通过它们每个请求。
以性能为中心的 cms 会采取不同的做法。例如，让主题说明主题激活期间需要哪些侧边栏、自定义帖子或任何其他元素。 wordpress 会记录下来并在内部进行适当调整。插件也是如此。但是，正如我之前所说，这样的程序会剥夺 cms 的很大灵活性，这是他们不感兴趣的。尖端：
- 限制插件数量
- 选择极简主题或只包含您需要的主题
- 他们会推荐你使用缓存插件，我不推荐。仅当您的网站速度非常慢时才使用它，并且要始终小心。我将在另一篇文章中讨论它（编辑：现在可用：不要在 wordpress 中使用缓存插件，尽管基本上这是因为你将基于钩子切断 wordpress 的所有内部工作。也就是说，你将强制 wordpress以一种方式工作，正如我们所看到的，这不是他们为他决定的方式。
几乎所有人都知道，wordpress 最初是一个基于另一个先前系统的博客系统。它不适用于大型项目，这就是为什么它的设计趋于简单。没有类，只有函数。与任何设计方面一样，这不一定是坏事（只是对那些使用 gtk 桌面的人说），除非您正在寻求灵活性。这就是头痛开始的时候。
如果您来自 php 世界，您可能会惊讶地发现，使用 wordpress，您甚至不需要执行 require、include 或 use 命名空间。这很容易理解，原因是 wordpress 总是加载其整个库。是的，总是如此，无论您是否使用它们。如果我们加上他患有阿尔茨海默氏症的事实，嗯。每个请求中必须读取 yes 或 yes 的代码行。通行证但是，当然，他认为这是因为灵活性。您可以使用核心函数，而不必包含明天可能具有不同名称或位于其他路径中的文件。
从 php 5.6 开始，提供了完整的函数命名空间支持。也许这就是 wordpress 的解决方案。但在这种情况下，他们将不得不做出造成向后不兼容的艰难决定。我不知道他们会做什么。
您无法对此进行改进，因为它是 wordpress 设计的一部分。您只需做好自己的部分，即确保您的代码不遵循该行。如果您决定这样做，以下是我的建议：
- 为“操作”创建匿名函数，这些函数只不过是包含您的代码的外部文件。因此，如果从未启动此操作，php 也不必解析所有代码。例子：
add\_action('admin\_init', function() {
include(\_\_dir\_\_."/zonas/panel/init.php");
});
add\_action('admin\_menu', function() {
include(\_\_dir\_\_."/zonas/panel/menu.php");
});
- 对于小部件、短代码和过滤器，请使用带有命名空间的类。此外，这些类是通过自动加载实例化的。
//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, ....
作为总结，我们看到 wordpress 具有简单性和灵活性的设计原则，但在某种程度上降低了其效率。你必须认为没有一种开发工具是万能的。如果有人这样送给你，那是因为他们在欺骗你，或者卖给你一把没有用的瑞士军刀。 wordpress 的速度缓慢，但对于展示网站来说，这不应该被重视。对于以网络为业务的网站，应考虑其他替代方案。对于流量大的网站也是如此。如果我们仍然想要 wordpress 的易用性和灵活性，我们必须知道我们必须用良好的托管、精心选择插件以及根据我们的需求定制的优质主题来补偿它。
