我的舊貼文 WordPress es un CMS lento 的英文版 - 2014
我不只一次陷入爭論：WordPress 慢嗎？好吧，當附加到 WordPress 的人的唯一答案是有很多訪問量的網站使用它並且它們的性能是最佳的時，這並沒有太大的爭論。這些人似乎忘記了，如果在功能強大的機器上“運行”，即使冒泡排序演算法對於過大的樣本也能表現良好。然而，如果我們考慮其計算複雜性，這並不意味著它一定是一種有效的演算法（事實上並非如此）。 WordPress 也會發生同樣的情況。考慮到相同數量的信息，它將需要比其他 CMS 更強大的託管。不僅如此，正如我們將看到的，無論是否有大量訊息，WordPress 本質上都很慢。
這並不代表 WordPress 不好。事實並非如此。就像汽車一樣，速度並不是一切。 CMS 領域也是如此。事實上，我的許多網路專案都是用它建構的。然而，每個項目都是不同的，因此，您需要明智地選擇最好的工具，而不是出於執著。
由於我是技術人員，所以我的論點將基於技術面。特別是當我了解到 WordPress 由於其設計而緩慢時。我邀請任何不同意的人發表評論並說明他們的理由。
在為 Web 專案設計資料庫架構時，會出現一個問題：是追求實用性還是追求效率。就 WordPress 而言，他們選擇了實用性，並將帖子、自訂帖子、資源和版本全部分組在一個表中：wp_posts。此操作的優點是簡化程式碼和搜尋（儘管這是 WordPress 難以解決的另一個問題，正如我們將在另一篇文章中看到的），但缺點是，它大大降低了 WordPress 的效率。一些例子可以讓這一點更清楚：
如果我們有 500 個帖子，每個帖子都有四個不同的修訂版（當前的一個和另外三個），就好像我們正在處理 2,000 個帖子。
如果我們在 WooCommerce 中有 500 種產品，並且每種產品都有一張特色圖片，並且產品庫中有四張，那麼就好像我們的 CMS 必須處理 3,000 種產品。
如果我們有一個包含35 個頁面和35 個選單項目的小型網站，無論是外部鏈接還是內部鏈接，我們的內容管理器都會像有70 個頁面一樣工作，因為每個選單項都算是我們CMS 中的一個條目或頁面。在此範例中，這可能看起來不多，但它顯示了影響效能的另一個因素。
如果您有 500 種四種語言的產品，您的 WordPress 將像處理 2,000 種產品一樣運作。
現在，讓我們總結一下現實世界的範例：如果您有一個包含500 個產品的網站，每個產品都有一個特色圖像、四個產品圖庫圖像和一個包含技術資訊的PDF，而該網站還有一個包含200 個條目的博客，每個條目都有各自的特色圖片。如果您的網站也支援三種語言，並且設定為每個貼文僅允許兩次修訂，則 WordPress 每次查詢資料庫時都必須搜尋超過 5,500 個項目。我忽略了其他因素，例如選單項目、頁面和自訂貼文。建議：
將修訂數量限制為兩次或完全停用它們：
// Limit revisions to two: define('WP_POST_REVISIONS', 2); // Completely disable revisions: // define('WP_POST_REVISIONS', false);
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.
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.
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:
add_action('admin_init', function() { include(__DIR__ . "/zones/panel/init.php"); }); add_action('admin_menu', function() { include(__DIR__ . "/zones/panel/menu.php"); });
// 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中文網其他相關文章！
