WordPress は遅い CMS です

この投稿は 2014 年に初めて公開されました。WordPress は遅い CMS - 2014

私は何度も、「WordPress は遅いのか?」という議論に巻き込まれたことがあります。まあ、WordPress に関わっている人たちからの唯一の反応が、アクセス数が多く、WordPress を使用しているサイトがあり、そのパフォーマンスが最適であるということだけであれば、それほど議論の余地はありません。彼ら自身は、バブルソートアルゴリズムでさえ、強力なコンピュータで「実行」されれば、過度に大きなサンプルに対して適切に動作することを忘れているようです。ただし、計算の複雑さを見ると、それが必ずしも効率的なアルゴリズムであるとは限りません (実際にはそうではありません)。 WordPress でも同じことが起こります。同じ量の情報を得るには、他の CMS よりもはるかに強力なホスティングが必要になります。それだけではなく、これからわか​​るように、情報量が多いかどうかに関係なく、すでに遅い CMS です。

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

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

すべてが 1 つのテーブルにあります。

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

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

• Woocommerce で 500 個の製品があり、それぞれに注目の画像が 1 つと、その製品のギャラリーとして 4 つある場合、CMS が 3,000 個の製品を処理する必要があるようなものです。

• 35 ページの小さな Web サイトがあり、そこには外部リンクまたは内部リンクを含む約 35 のメニュー項目があるとします。私たちのコンテンツ マネージャーは、あたかも 70 ページがあるかのように機能します。各メニュー項目は CMS のエントリまたはページであるかのようにカウントされるためです。この例では、それは大したことではありませんが、影響を与える別の要因がわかるようにこれを入れています。

• 500 個の製品と 4 つの言語がある場合、WordPress はあたかも 2,000 個の製品で動作したかのようになります。

• それでは、要約として実際の例を見てみましょう: 500 個の製品を含む Web サイトがあり、それぞれの製品に注目の画像、4 つの製品ギャラリー画像、および各製品の技術情報を含む PDF があるとします。 。さらに、このサイトには 200 件のエントリーがあり、それぞれに対応する注目の画像が含まれるブログもあります。また、3 つの言語をサポートし、投稿ごとにレビューが 2 つだけになるようにウェブサイトを作成した場合。 WordPress がデータベースに対してクエリを実行するたびに、5,500 を超える要素の中から検索する必要があります。私はメニュー項目、ページ、カスタム投稿などを軽蔑します。ヒント:

• レビューの数を 2 つに制限するか、レビューを完全に無効にします:
  

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