WordPress ist ein langsames CMS

Dieser Beitrag wurde erstmals 2014 in WordPress ist ein langsames CMS – 2014 veröffentlicht

Mehr als einmal war ich in die Debatte verwickelt: Ist WordPress langsam? Nun, es ist nicht so eine große Debatte, wenn die einzige Antwort derjenigen, die mit WordPress verbunden sind, darin besteht, dass es Websites mit vielen Besuchen gibt, die es haben und deren Leistung optimal ist. Sie selbst scheinen zu vergessen, dass selbst der Blasensortierungsalgorithmus bei übermäßig großen Stichproben gut funktioniert, wenn er auf einem leistungsstarken Computer „ausgeführt“ wird. Dies bedeutet jedoch nicht, dass es sich unbedingt um einen effizienten Algorithmus handelt (tatsächlich ist er es auch nicht), wenn wir seine Rechenkomplexität betrachten. Das Gleiche passiert mit WordPress. Für die gleiche Menge an Informationen ist ein wesentlich leistungsfähigeres Hosting erforderlich als bei anderen CMS. Darüber hinaus ist es, wie wir sehen werden, bereits ein langsames CMS, unabhängig davon, ob es viele Informationen enthält oder nicht.

Das bedeutet nicht, dass WordPress schlecht ist. Nichts könnte weiter von der Wahrheit entfernt sein. Genau wie bei einem Auto ist Geschwindigkeit nicht alles. Das Gleiche passiert in der Welt der CMS. Tatsächlich ist ein großer Teil meiner Webprojekte damit verbunden. Allerdings ist jedes Projekt anders und deshalb müssen Sie wissen, wie Sie die besten Werkzeuge mit Ihrem Kopf und nicht mit Eigensinn auswählen.

Da ich ein technischer Mensch bin, basieren meine Argumente auf technischen Aspekten. Vor allem, wenn ich verstehe, dass WordPress aufgrund seines Designs langsam ist. Ich lade alle, die anderer Meinung sind, ein, mir einen Kommentar mit ihrer Begründung zu hinterlassen.

Alles in einer Tabelle.

Wenn wir ein Datenbankschema für ein Webprojekt erstellen, stellt sich die Frage, ob wir uns für das Praktische oder das Effiziente entscheiden sollen. Im Fall von WordPress haben sie sich für Praktikabilität entschieden und Beiträge, benutzerdefinierte Beiträge, Ressourcen und Versionen in derselben Tabelle gruppiert: wp_posts. Diese Aktion hat den Vorteil, dass sie den Code und die Suche vereinfacht (obwohl dies eine weitere Sache ist, die WordPress fehlt, wie wir in einem anderen Beitrag sehen werden), aber andererseits verringert sie drastisch die Effizienz von WordPress. Einige Beispiele zum Verständnis:

• Wenn wir 500 Beiträge haben und jeder davon vier verschiedene Rezensionen hat (die aktuelle und drei weitere), ist es so, als hätten wir es mit 2.000 Beiträgen zu tun.

• Wenn wir 500 Produkte mit Woocommerce haben und jedes davon ein vorgestelltes Bild und vier als Galerie dieses Produkts hat, ist es, als ob unser CMS mit 3.000 Produkten arbeiten müsste.

• Wenn wir eine kleine Website mit 35 Seiten haben und darauf etwa 35 Menüpunkte haben, entweder mit externen oder internen Links. Unser Content Manager würde so arbeiten, als ob wir 70 Seiten hätten. Denn jeder Menüpunkt zählt, als wäre er ein Eintrag oder eine Seite in unserem CMS. In diesem Beispiel ist das nicht viel, aber ich habe es so ausgedrückt, dass Sie einen weiteren Einflussfaktor sehen können.

• Wenn Sie 500 Produkte und vier Sprachen haben, ist Ihr WordPress so, als ob es bei 2.000 Produkten funktionieren würde.

• Kommen wir nun als Zusammenfassung zu einem realen Beispiel: Wenn Sie eine Website mit 500 Produkten haben und für jedes davon auch ein vorgestelltes Bild, vier Produktgaleriebilder und ein PDF mit technischen Informationen zu jedem Produkt haben . Darüber hinaus gibt es auf dieser Seite auch einen Blog mit jeweils 200 Einträgen und den dazugehörigen Bildern. Auch wenn Sie die Website mit Unterstützung für drei Sprachen erstellt und so eingerichtet haben, dass es nur zwei Bewertungen pro Beitrag gibt. Jedes Mal, wenn WordPress eine Abfrage in Ihrer Datenbank startet, muss es mehr als 5.500 Elemente durchsuchen. Ich verachte andere wie Menüpunkte, Seiten und benutzerdefinierte Beiträge. Tipps:

• Begrenzen Sie die Anzahl der Bewertungen auf zwei oder deaktivieren Sie Bewertungen vollständig:
  

    //Limita las revisiones a dos:
    define( 'WP\_POST\_REVISIONS', 2 );
    //Desactiva totalmente las revisiones:
    //define( 'WP\_POST\_REVISIONS', false );

• Löschen Sie von Zeit zu Zeit alle Revisionen. Sie können dies tun, indem Sie die folgende SQL-Abfrage starten:

    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'

• Seien Sie streng mit den Bildern auf Ihrer Website. Fügen Sie Ihrem CMS auch keine Bilder hinzu, die Sie nicht verwenden werden.

• Vermeiden Sie eine Vielzahl von Menüs, wenn diese nicht unbedingt erforderlich sind. Löschen Sie Menüeinträge, die Sie nicht verwenden werden.

• Wenn Sie keine andere Wahl haben, als WordPress für mittlere oder große Projekte zu verwenden, weil Ihr Kunde darauf besteht, versuchen Sie, Hilfstabellen zu erstellen und so die Belastung von wp_posts so weit wie möglich zu verringern

Ihr WordPress hat Alzheimer

WordPress strebt nach Flexibilität um jeden Preis, auch auf Kosten der Geschwindigkeit. Vielleicht, weil es am Anfang nur ein Blog-System sein sollte und so viel Flexibilität dann nicht so viel Schaden anrichten konnte. Wir begannen jedoch, es als CMS zu verwenden, und zu diesem Zeitpunkt begannen die durch die Flexibilität verursachten Leistungsprobleme.

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.

Das obige ist der detaillierte Inhalt vonWordPress ist ein langsames CMS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!