WordPress는 느린 CMS입니다.

이 게시물은 2014년에 처음 게시되었습니다. WordPress is a Slow CMS - 2014

저는 WordPress가 느린가요?라는 논쟁에 여러 번 참여했습니다. 글쎄, WordPress에 연결된 사람들의 유일한 응답이 WordPress를 많이 방문하는 사이트가 있고 성능이 최적이라는 것이라면 그다지 논쟁의 여지가 없습니다. 그들은 버블 정렬 알고리즘조차도 강력한 컴퓨터에서 "실행"된다면 지나치게 큰 샘플에 대해 잘 작동한다는 사실을 스스로 잊어버린 것 같습니다. 그러나 이것이 계산 복잡성을 살펴보면 반드시 효율적인 알고리즘이라는 것을 의미하지는 않습니다(실제로는 그렇지 않습니다). WordPress에서도 같은 일이 발생합니다. 동일한 양의 정보를 얻으려면 다른 CMS보다 훨씬 더 강력한 호스팅이 필요합니다. 그뿐만 아니라, 앞으로 살펴보겠지만, 정보가 많든 없든 이미 느린 CMS입니다.

워드프레스(WordPress)가 나쁘다는 뜻은 아닙니다. 진실에서 더 이상 벗어날 수 있는 것은 없습니다. 자동차와 마찬가지로 속도가 전부는 아닙니다. CMS의 세계에서도 똑같은 일이 일어납니다. 사실 내 웹 프로젝트의 대부분이 이 기능을 사용하고 있습니다. 하지만 프로젝트마다 다르기 때문에 집착이 아닌 머리로 적절하게 최고의 도구를 선택하는 방법을 알아야 합니다.

나는 기술적인 사람이기 때문에 나의 주장은 기술적인 측면을 기반으로 할 것입니다. 특히 WordPress가 디자인 때문에 느리다는 것을 이해하면 더욱 그렇습니다. 동의하지 않는 모든 분들은 의견을 댓글로 남겨주시기 바랍니다.

하나의 테이블에 모든 것이 있습니다.

웹 프로젝트용 데이터베이스 스키마를 생성할 때 실용적인 방법을 택할 것인지 효율적인 방법을 택할 것인지에 대한 의문이 생깁니다. WordPress의 경우 실용성과 그룹화된 게시물, 사용자 정의 게시물, 리소스 및 버전을 동일한 테이블인 wp_posts에 선택했습니다. 이 작업은 코드와 검색을 단순화하는 이점이 있지만(다른 게시물에서 볼 수 있듯이 이는 WordPress에 부족한 또 다른 기능이지만) 반면에 WordPress의 효율성을 크게 떨어뜨립니다. 이해해야 할 몇 가지 예:

• 500개의 게시물이 있고 각 게시물에 4개의 다른 리뷰(현재 1개와 3개가 더 있음)가 있으면 2,000개의 게시물을 처리하는 것과 같습니다.

• WooCommerce에 500개의 제품이 있고 각각에 추천 이미지가 있고 해당 제품의 갤러리로 4개가 있다면 CMS가 3,000개의 제품을 처리해야 하는 것과 같습니다.

• 35페이지의 작은 웹사이트가 있고 그 안에 외부 또는 내부 링크가 포함된 약 35개의 메뉴 항목이 있는 경우. 우리의 콘텐츠 관리자는 마치 70페이지가 있는 것처럼 작동합니다. 각 메뉴 항목은 CMS의 항목이나 페이지인 것처럼 계산됩니다. 이 예에서는 많지는 않지만 또 다른 영향 요인을 볼 수 있도록 넣었습니다.

• 500개의 제품과 4개의 언어가 있다면 WordPress는 2,000개의 제품에서 작동하는 것과 같습니다.

• 이제 요약된 실제 예를 살펴보겠습니다. 500개의 제품이 있는 웹사이트가 있고 각 제품에 대한 추천 이미지, 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에 알츠하이머병이 있습니다.

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 중국어 웹사이트의 기타 관련 기사를 참조하세요!