WordPress 是一個緩慢的 CMS

這篇文章最初於 2014 年在 WordPress 中發布，是一個緩慢的 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 時，靈活性導致的效能問題就開始出現了。

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中文網其他相關文章！