Yavaş Bir WordPress Sitesini Hızlandırmak: Gerçek Çalışma Sırası

"WordPress sitemiz yavaşladı" aldığım en yaygın isteklerden biri, ve içgüdü genelde bir plugin'le başlamak oluyor, bir image optimizer, her şeyi düzeltmeyi vadeden bir "speed" plugin'i. Bazen bu biraz yardımcı oluyor. Ama en büyük kazançlar neredeyse her zaman WordPress'in plugin ekosistemiyle hiçbir ilgisi olmayan şeylerden geliyor, ve bunları yanlış sırada yapmak, diğer 70%'e sebep olan şeyi düzeltmeden önce %10'luk bir iyileştirmeye zaman harcamak demek.

Önce: server mi, sayfa mı?

Herhangi bir şeye dokunmadan önce, time-to-first-byte'a bakıyorum, server'ın bir response göndermeye başlaması ne kadar sürüyor, browser'ın bundan sonra her şeyi yüklemesi ne kadar sürüyor sorusundan ayrı olarak:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com

Logged-out bir sayfada yarım saniyenin üzerinde bir TTFB, genelde WordPress'in her request'te gerçek iş yaptığı anlamına geliyor, database query'leniyor, PHP execute ediliyor, hiçbir şey cache'lenmiyor. Hızlı bir TTFB ama yavaş bir overall page load, frontend'e işaret ediyor, image'lar, script'ler, font'lar, ki bu farklı (ve genelde daha kolay) bir problem.

Server'sa: katmanlar halinde caching

Her visitor için aynı olan bir WordPress sayfası (ki bu çoğu sitedeki çoğu sayfayı tanımlıyor), her request'te PHP ve MySQL'in çalışmasına ihtiyaç duymuyor. WP Super Cache gibi bir plugin üzerinden, ya da daha iyisi, Nginx'in fcgicache'i ya da benzer bir reverse proxy cache'iyle server seviyesinde bir page cache, static bir kopya serve ediyor ve cache'lenmiş request'ler için PHP'yi tamamen atlıyor. Bu tek değişiklik genelde 800ms'lik bir TTFB ile 50ms arasındaki fark oluyor, çünkü bu "WordPress'i çalıştır" ile "bir dosya serve et" arasındaki fark.

Gerçekten PHP'ye ihtiyaç duyan request'ler için, logged-in user'lar, herhangi bir dinamik şey, bir object cache (Redis ya da Memcached), WordPress'in database query'lerinin sonuçlarını cache'liyor, böylece tekrarlanan lookup'lar (WordPress bunlardan çok yapıyor, genelde aynı query sayfa başına onlarca kez) MySQL'e değil memory'ye gidiyor:

// wp-config.php, after installing a Redis object cache plugin
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Ve compile edilmiş PHP bytecode'unu cache'leyen, böylece aynı dosyanın her request'te yeniden compile edilmemesini sağlayan PHP'nin OPcache'i, basitçe php.ini'de enable edilmeli, bunun hiç WordPress'e özel bir configuration'ı yok ve server'daki her PHP request'ine fayda sağlıyor.

Database ağırlık biriktiriyor

WordPress'in database'i, fark edilene kadar fark edilmeyen şekillerde büyüyor: post revision'ları (her autosave yeni bir row oluşturuyor), expired transient'lar (genelde hiç temizlenmeyen geçici cache'lenmiş data), ve kaldırılmış plugin'lerden kalan orphaned metadata. Küçük bir sitede bunların hiçbiri dramatik değil, ama yıllardır çalışan bir sitede, autoload edilen option'ların (ihtiyaç olsun olmasın her sayfa request'inde yüklenen) birkaç megabyte'a ulaştığı bir wp_options tablosu bulmak yaygın:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 10;

Burada büyük olan ve artık aktif olmayan bir plugin'den gelen her şey, her tek request'te saf overhead. Bunu temizlemek tahmin gerektirmiyor, query ağırlığın tam olarak nerede olduğunu söylüyor.

Sonra, ve sadece sonra, frontend

Server hızlı cevap verdiğinde, frontend optimization'ın, image'larda lazy-loading'in, modern image format'ları serve etmenin, kritik olmayan script'leri deferring etmenin, üzerine inşa edecek gerçek bir foundation'ı oluyor. Bunu 800ms TTFB'si olan bir sitede önce yapmak, görünmeyen %80 (browser'ın render etmeye başlamadan önceki süre) hiç dokunulmadan kalırken görünen %20'yi parlatmak demek.

Sıra neden önemli

Bu adımların her biri tek başına kullanışlı, ama sıra, zamanın tipik yavaş bir WordPress sitesinde gerçekte nereye gittiğini yansıtıyor: server-side caching, logged-out traffic için en büyük parçayı ele alıyor, object cache ve OPcache, diğer her şey için WordPress'in kendisinin maliyetini ele alıyor, database cleanup her tek sayfayı etkileyen birikmiş ağırlığı kaldırıyor, ve frontend optimization kalanı parlatıyor. Bu listenin en sonundan başlamak, en görünür olduğu için, bir image, bir script, üretken hissettiriyor, ama toplam zamanın en küçük parçasını önce optimize etmek demek.