WordPress는 느린 CMS입니다

내 이전 게시물의 영어 버전 WordPress es un CMS lento - 2014

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

워드프레스(WordPress)가 나쁘다는 뜻은 아닙니다. 진실에서 더 이상 벗어날 수 있는 것은 없습니다. 자동차와 마찬가지로 속도가 전부는 아닙니다. CMS의 세계도 마찬가지입니다. 사실, 내 웹 프로젝트 중 상당수가 이를 사용하여 구축되었습니다. 하지만 프로젝트마다 다르기 때문에 집착이 아닌 현명하게 최고의 도구를 선택해야 합니다.

나는 기술적인 사람이기 때문에 나의 주장은 기술적인 측면을 기반으로 할 것입니다. 특히 WordPress가 디자인 때문에 느리다는 것을 알고 있을 때 그렇습니다. 동의하지 않는 분들은 이유를 댓글로 남겨주세요.

올인원 테이블

웹 프로젝트를 위한 데이터베이스 스키마를 설계할 때 실용성을 추구할 것인지, 효율성을 추구할 것인지에 대한 의문이 생깁니다. WordPress의 경우 실용성과 그룹화된 게시물, 사용자 정의 게시물, 리소스 및 버전을 모두 하나의 테이블(wp_posts)에 선택했습니다. 이 작업은 코드와 검색을 단순화하는 이점이 있지만(다른 게시물에서 볼 수 있듯이 WordPress가 어려움을 겪는 또 다른 문제임에도 불구하고) 단점은 WordPress의 효율성을 크게 감소시킵니다. 이를 더욱 명확하게 하기 위한 몇 가지 예:

• 500개의 게시물이 있고 각 게시물에 4개의 다른 수정본(현재 1개와 3개 추가)이 있다면 이는 마치 2,000개의 게시물을 처리하는 것과 같습니다.

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

• 외부 링크든 내부 링크든 35페이지와 35개 메뉴 항목이 있는 작은 웹사이트가 있는 경우 각 메뉴 항목이 CMS의 항목이나 페이지로 계산되므로 콘텐츠 관리자는 마치 70페이지가 있는 것처럼 작동합니다. . 이 예에서는 별 것 아닌 것처럼 보일 수도 있지만 성능에 영향을 미치는 또 다른 요소를 보여줍니다.

• 4개 언어로 된 500개의 제품이 있는 경우 WordPress는 2,000개의 제품을 처리하는 것처럼 작동합니다.

• 이제 실제 사례를 요약해 보겠습니다. 각 제품에는 추천 이미지, 4개의 제품 갤러리 이미지, 기술 정보가 포함된 PDF가 포함된 500개의 제품이 있는 웹사이트가 있고 사이트에는 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는 속도를 희생하더라도 유연성을 추구합니다. 어쩌면 처음에는 블로그 시스템만 할 예정이었기 때문에 그렇게 유연성을 키워도 큰 피해를 입지는 않았을 것입니다. 그런데 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!