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 时，这种灵活性导致的性能问题开始出现。

Let me give you some bad news: your content manager has Alzheimer’s. It forgets everything from one request to another. You will have to repeat each time which custom posts, sidebars, or menus you are going to use. There is no other choice because it forgets. That's why, for example, if you want to add an entry to the admin menu, you will have to tell it every time it is to be displayed. Yes, it offers enormous flexibility, but it forces PHP and the CMS to process the same thing repeatedly, resulting in a loss of efficiency. The same thing happens with plugins, which is why many plugins can significantly slow down your website. It’s not because of the plugin system itself (which is magnificently designed and programmed) but because plugins have to declare the same information repeatedly, forcing WordPress to go through them entirely with every request.

A performance-focused CMS would have done it differently. For example, by having the theme declare during activation what sidebars, custom posts, or other elements it needs. WordPress would register this information and adjust internally. The same could be applied to plugins. But, as mentioned earlier, such an approach would significantly reduce the CMS's flexibility, which is not desirable.

Tips:

• Limit the number of plugins.

• Choose minimalist themes that only have what you need.

• You might be advised to use a cache plugin; I don't. Only use one if your website is extremely slow and do so with caution. I will discuss this in another post (edit: now available: Don’t Use Cache Plugins with WordPress, but basically, it’s because you will disable all of WordPress’s internal workings based on hooks. That is, you will force WordPress to work in a way that is not intended.

Everything Always Available

As almost everyone knows, WordPress started as a blogging system based on a previous system. It wasn't designed for large projects, which is why its design leaned toward simplicity. No classes, just functions. As with any design aspect, this doesn’t have to be a bad thing (just ask those using desktops built with GTK) unless you are looking for flexibility. Then, the headaches begin.

If you come from the PHP world, you might be surprised that with WordPress, you don’t have to use "require," "include," or "namespace." This is easy to understand: WordPress always loads its entire arsenal of libraries. Yes, always, whether you use them or not. When you combine this with its memory issues, well... that's a lot of code to read with every request. But, of course, this is all for flexibility. You can use a core function without having to include a file that might change names or paths tomorrow.

Since PHP 5.6, there is full support for function namespaces. Maybe this is a solution for WordPress. But in that case, they will have to make the difficult decision of breaking backward compatibility. I don't know what they will do.

There’s nothing you can do to improve this, as it’s part of WordPress’s design. All you can do is your part: make sure your code doesn't follow this path. If you decide to do so, here are my tips:

• Create anonymous functions for "actions" that are nothing more than includes to external files where you keep your code. This way, if the action never triggers, PHP won’t have to parse all the code. Example:

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

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

• For widgets, shortcodes, and filters, use classes with namespaces. Also, make sure these classes are instantiated using autoloading.

// 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...

In summary, we have seen that WordPress's design principles are simplicity and flexibility, but in a way that sacrifices efficiency. It is essential to understand that no development tool is good for everything. If someone presents it that way, they are either misleading you or selling you a Swiss army knife that is good for nothing.

WordPress struggles with speed, but for showcase websites, this is not something to worry about. However, for websites where the business relies on the web, or for sites with a lot of traffic, alternative options should be considered. Still, if we choose WordPress for its ease of use and flexibility, we must compensate by investing in good hosting, being very careful with the selection of plugins, and using a high-quality theme tailored to our needs.

以上是WordPress 是一个缓慢的 CMS的详细内容。更多信息请关注PHP中文网其他相关文章！