WordPress ialah CMS Lambat

Versi bahasa Inggeris bagi catatan lama saya WordPress es un CMS lento - 2014

Lebih daripada sekali, saya mendapati diri saya berada di tengah-tengah perdebatan: Adakah WordPress lambat? Nah, ia bukanlah satu perdebatan apabila satu-satunya jawapan daripada mereka yang dilampirkan pada WordPress ialah terdapat tapak dengan banyak lawatan menggunakannya, dan prestasinya adalah optimum. Orang-orang ini nampaknya lupa bahawa walaupun algoritma isihan gelembung Isih gelembung berfungsi dengan baik untuk sampel yang terlalu besar jika "dijalankan" pada mesin yang berkuasa. Walau bagaimanapun, ini tidak bermakna ia semestinya algoritma yang cekap (sebenarnya tidak) jika kita mempertimbangkan kerumitan pengiraannya. Perkara yang sama berlaku dengan WordPress. Memandangkan jumlah maklumat yang sama, ia memerlukan pengehosan yang lebih berkuasa daripada CMS lain. Bukan itu sahaja, tetapi seperti yang akan kita lihat, WordPress sememangnya perlahan sama ada ia mempunyai banyak maklumat atau tidak.

Ini tidak bermakna WordPress adalah buruk. Tidak ada yang lebih jauh dari kebenaran. Sama seperti dalam kereta, kelajuan bukanlah segala-galanya. Begitu juga dengan dunia CMS. Malah, banyak projek web saya dibina dengannya. Walau bagaimanapun, setiap projek adalah berbeza, dan oleh itu, anda perlu memilih alatan terbaik dengan bijak, bukan di luar lampiran.

Memandangkan saya seorang yang teknikal, hujah saya akan berdasarkan aspek teknikal. Terutama apabila saya faham bahawa WordPress adalah perlahan kerana reka bentuknya. Saya menjemput sesiapa sahaja yang tidak bersetuju untuk meninggalkan komen dengan alasan mereka.

Semua dalam Satu Meja

Apabila mereka bentuk skema pangkalan data untuk projek web, persoalan timbul sama ada mahu menggunakan kepraktisan atau kecekapan. Dalam kes WordPress, mereka memilih kepraktisan dan mengumpulkan siaran, siaran tersuai, sumber dan versi semuanya dalam satu jadual: wp_posts. Tindakan ini mempunyai kelebihan untuk memudahkan kod dan carian (walaupun ini adalah isu lain yang dihadapi oleh WordPress, seperti yang akan kita lihat dalam siaran lain), tetapi pada sisi negatifnya, ia secara drastik mengurangkan kecekapan WordPress. Beberapa contoh untuk menjadikannya lebih jelas:

• Jika kami mempunyai 500 siaran, dan setiap satu mempunyai empat semakan berbeza (satu semasa dan tiga lagi), seolah-olah kami sedang berurusan dengan 2,000 siaran.

• Jika kami mempunyai 500 produk dengan WooCommerce, dan setiap satu mempunyai imej yang ditampilkan dan empat dalam galeri produk, seolah-olah CMS kami terpaksa mengendalikan 3,000 produk.

• Jika kami mempunyai tapak web kecil dengan 35 halaman dan 35 item menu, sama ada pautan luaran atau dalaman, pengurus kandungan kami akan berfungsi seolah-olah terdapat 70 halaman kerana setiap item menu dikira sebagai entri atau halaman dalam CMS kami . Ini mungkin tidak kelihatan dalam contoh ini, tetapi ia menunjukkan faktor lain yang mempengaruhi prestasi.

• Jika anda mempunyai 500 produk dalam empat bahasa, WordPress anda akan bertindak seolah-olah ia mengendalikan 2,000 produk.

• Sekarang, mari kita pergi ke contoh dunia nyata secara ringkasan: Jika anda mempunyai tapak web dengan 500 produk, setiap satu dengan imej yang ditampilkan, empat imej galeri produk dan PDF dengan maklumat teknikal dan tapak itu juga mempunyai blog dengan 200 entri, setiap satu dengan imej pilihan masing-masing. Jika tapak anda turut menyokong tiga bahasa dan ditetapkan untuk membenarkan hanya dua semakan setiap siaran, WordPress mesti mencari melalui lebih 5,500 item setiap kali ia menanyakan pangkalan data anda. Saya mengabaikan faktor lain seperti item menu, halaman dan siaran tersuai. Nasihat:

• Hadkan bilangan semakan kepada dua atau lumpuhkan semakan sepenuhnya:
  

// Limit revisions to two:
define('WP_POST_REVISIONS', 2);
// Completely disable revisions:
// define('WP_POST_REVISIONS', false);

• Padam semua semakan dari semasa ke semasa. Anda boleh melakukan ini dengan menjalankan pertanyaan SQL berikut:

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';

• Berjimat-cermat dengan imej di tapak web anda. Jangan tambahkan imej pada CMS anda yang anda tidak akan gunakan.

• Elakkan mempunyai berbilang menu melainkan ia penting. Alih keluar masukan menu yang anda tidak mahu gunakan.

• Jika anda tiada pilihan lain, kerana pelanggan anda berkeras mahu menggunakan WordPress untuk projek sederhana atau besar, cuba buat jadual tambahan untuk meringankan beban pada wp_posts sebanyak mungkin.

WordPress Anda Menghidap Alzheimer

WordPress mencari fleksibiliti pada sebarang kos, walaupun dengan mengorbankan kelajuan. Mungkin kerana pada permulaannya, ia hanya akan menjadi sistem blog, dan dalam kes itu, begitu banyak fleksibiliti tidak akan menyebabkan banyak kerosakan. Namun, apabila kami mula menggunakannya sebagai CMS, masalah prestasi yang disebabkan oleh fleksibiliti ini mula timbul.

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.

Atas ialah kandungan terperinci WordPress ialah CMS Lambat. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!