WordPress は遅い CMS です

私の古い投稿 WordPress es un CMS lento - 2014 の英語版

私は何度も、「WordPress は遅いのか?」という議論の真っ只中にいることがありました。まあ、WordPress に関わっている人たちの唯一の答えが、多くのアクセスがあり、WordPress を使用しているサイトがあり、そのパフォーマンスが最適であるということだけであれば、それほど議論の余地はありません。これらの人々は、バブル ソート アルゴリズムであるバブル ソートでも、強力なマシンで「実行」すれば、過度に大きなサンプルに対して適切にパフォーマンスを発揮することを忘れているようです。ただし、計算の複雑さを考慮すると、これが必ずしも効率的なアルゴリズムであることを意味するわけではありません (実際にはそうではありません)。 WordPressでも同じことが起こります。同じ量の情報があれば、他の CMS よりもはるかに強力なホスティングが必要になります。それだけではなく、これから説明するように、WordPress は情報量が多いかどうかに関係なく、本質的に遅いのです。

これは WordPress が悪いという意味ではありません。これ以上真実からかけ離れたものはありません。車と同じように、スピードがすべてではありません。 CMSの世界でも同様です。実際、私の Web プロジェクトの多くはこれを使用して構築されています。ただし、プロジェクトはそれぞれ異なるため、愛着からではなく、賢明に最適なツールを選択する必要があります。

私は技術者なので、私の議論は技術的な側面に基づいて行われます。特に WordPress がデザインのせいで遅いと理解しているときはそうです。同意しない人は、その理由をコメントに残してください。

オールインワンテーブル

Web プロジェクトのデータベース スキーマを設計するとき、実用性を重視するか効率性を重視するかという問題が生じます。 WordPress の場合、実用性を選択し、投稿、カスタム投稿、リソース、バージョンをすべて 1 つのテーブル wp_posts にグループ化しました。このアクションには、コードと検索が簡素化されるという利点があります (これは、別の投稿で説明するように、WordPress が苦労しているもう 1 つの問題ですが) が、欠点として、WordPress の効率が大幅に低下します。これを明確にするためのいくつかの例:

• 500 件の投稿があり、それぞれに 4 つの異なるリビジョン (現在のものとさらに 3 つ) がある場合、あたかも 2,000 件の投稿を処理しているようなものです。

• WooCommerce で 500 個の商品があり、それぞれに注目の画像と商品ギャラリーに 4 つの商品がある場合、CMS は 3,000 個の商品を処理しなければならないようなものです。

• 外部リンクか内部リンクかを問わず、35 ページと 35 のメニュー項目がある小規模な Web サイトがある場合、各メニュー項目は CMS のエントリまたはページとしてカウントされるため、コンテンツ マネージャーはあたかも 70 ページがあるかのように動作します。 。この例では大したことではないように見えますが、パフォーマンスに影響を与える別の要因を示しています。

• 4 つの言語で 500 個の製品がある場合、WordPress は 2,000 個の製品を処理しているかのように動作します。

• それでは、実際の例を要約して見てみましょう。Web サイトに 500 個の製品があり、それぞれに注目の画像、4 つの製品ギャラリー画像、技術情報を含む PDF が含まれているとします。のブログには 200 のエントリがあり、それぞれに注目の画像が付いています。サイトが 3 つの言語もサポートしており、投稿ごとに 2 つのリビジョンのみを許可するように設定されている場合、WordPress はデータベースにクエリを実行するたびに 5,500 を超えるアイテムを検索する必要があります。メニュー項目、ページ、カスタム投稿などの他の要素は無視します。アドバイス:

• リビジョンの数を 2 に制限するか、完全に無効にします:
  

// 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 中国語 Web サイトの他の関連記事を参照してください。