WordPress 是一个缓慢的 CMS

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《WordPress 是一个缓慢的 CMS》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

我的旧帖子 wordpress es un cms lento 的英文版 - 2014

我不止一次地陷入争论：wordpress 慢吗？好吧，当附加到 wordpress 的人的唯一答案是有很多访问量的网站使用它并且它们的性能是最佳的时，这并没有太大的争论。这些人似乎忘记了，如果在功能强大的机器上“运行”，即使冒泡排序算法对于过大的样本也能表现良好。然而，如果我们考虑其计算复杂性，这并不意味着它一定是一种有效的算法（事实上并非如此）。 wordpress 也会发生同样的情况。考虑到相同数量的信息，它将需要比其他 cms 更强大的托管。不仅如此，正如我们将看到的，无论是否有大量信息，wordpress 本质上都很慢。

这并不意味着 wordpress 不好。事实并非如此。就像汽车一样，速度并不是一切。 cms 领域也是如此。事实上，我的许多网络项目都是用它构建的。然而，每个项目都是不同的，因此，您需要明智地选择最好的工具，而不是出于执着。

由于我是技术人员，所以我的论点将基于技术方面。特别是当我了解到 wordpress 由于其设计而缓慢时。我邀请任何不同意的人发表评论并说明他们的理由。

一切尽在一张桌子上

在为 web 项目设计数据库模式时，会出现一个问题：是追求实用性还是效率。就 wordpress 而言，他们选择了实用性，并将帖子、自定义帖子、资源和版本全部分组在一个表中：wp_posts。此操作的优点是简化代码和搜索（尽管这是 wordpress 难以解决的另一个问题，正如我们将在另一篇文章中看到的），但缺点是，它大大降低了 wordpress 的效率。一些例子可以让这一点更清楚：

• 如果我们有 500 个帖子，每个帖子都有四个不同的修订版（当前的一个和另外三个），就好像我们正在处理 2,000 个帖子。

• 如果我们在 woocommerce 中有 500 种产品，并且每种产品都有一张特色图片，并且产品库中有四张，那么就好像我们的 cms 必须处理 3,000 种产品。

• 如果我们有一个包含 35 个页面和 35 个菜单项的小型网站，无论是外部链接还是内部链接，我们的内容管理器都会像有 70 个页面一样工作，因为每个菜单项都算作我们 cms 中的一个条目或页面。在此示例中，这可能看起来不多，但它显示了影响性能的另一个因素。

• 如果您有 500 种四种语言的产品，您的 wordpress 将像处理 2,000 种产品一样运行。

• 现在，让我们总结一下现实世界的示例：如果您有一个包含 500 个产品的网站，每个产品都有一个特色图像、四个产品图库图像和一个包含技术信息的 pdf，并且该网站还有一个包含 200 个条目的博客，每个条目都有各自的特色图片。如果您的网站还支持三种语言，并且设置为每个帖子仅允许两次修订，则 wordpress 每次查询数据库时都必须搜索超过 5,500 个项目。我忽略了其他因素，例如菜单项、页面和自定义帖子。建议：

• 将修订数量限制为两次或完全禁用它们：
  

// limit revisions to two:
define('wp_post_revisions', 2);
// completely disable revisions:
// 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”或“命名空间”。这很容易理解：wordpress 总是加载其整个库。是的，总是如此，无论您是否使用它们。当你将其与内存问题结合起来时，嗯......每个请求都需要阅读大量代码。但是，当然，这都是为了灵活性。您可以使用核心函数，而不必包含明天可能会更改名称或路径的文件。

从 php 5.6 开始，完全支持函数命名空间。也许这就是 wordpress 的解决方案。但在这种情况下，他们将不得不做出打破向后兼容性的艰难决定。我不知道他们会做什么。

您无法对此进行改进，因为它是 wordpress 设计的一部分。您所能做的就是您的部分：确保您的代码不遵循此路径。如果您决定这样做，以下是我的建议：

• 为“操作”创建匿名函数，这些函数只不过是包含到您保存代码的外部文件中。这样，如果操作永远不会触发，php 就不必解析所有代码。例子：

add_action('admin_init', function() {
    include(__dir__ . "/zones/panel/init.php");
});

add_action('admin_menu', function() {
    include(__dir__ . "/zones/panel/menu.php");
});

• 对于小部件、短代码和过滤器，请使用带有命名空间的类。另外，请确保使用自动加载来实例化这些类。

// It's better to use: spl_autoload_register()

function __autoload($classname) {
    $file = str_replace('\\', DIRECTORY_SEPARATOR, $classname);

    include_once(BASE_PATH . $file . '.php');
}

add_shortcode('block', array('misshortcodesBlock', 'load'));
//... my other shortcodes, filters, and widgets...

综上所述，我们看到wordpress的设计原则是简单和灵活，但在某种程度上牺牲了效率。重要的是要明白，没有一种开发工具是万能的。如果有人这样介绍，他们要么是在误导你，要么是在向你推销一把毫无用处的瑞士军刀。

wordpress 的速度较慢，但​​对于展示型网站来说，这并不是什么值得担心的事情。然而，对于业务依赖网络的网站，或者流量很大的网站，应该考虑替代选项。尽管如此，如果我们选择 wordpress 是因为它的易用性和灵活性，我们必须通过投资良好的托管、谨慎选择插件以及使用适合我们需求的高质量主题来弥补。

今天关于《WordPress 是一个缓慢的 CMS》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！