Paylaşımlı hostingde gerçek bir mobil PageSpeed 97: jekcms'te hangi mekanizma LCP, CLS ve TBT'yi oynatıyor — ve hangi rakamı uydurmayı reddediyorum.
jekcms üzerinde işlettiğim 14 içerik sitesinden biri mobil PageSpeed'de 97 ölçüyor. Altyapı bilerek gösterişsiz: paylaşımlı LiteSpeed hosting, önünde Cloudflare. VPS yok, edge worker yok, konferansta övünülecek hiçbir şey yok. CMS hızlı olmak için pahalı altyapı isteseydi bunu bir bug sayardım — yazılımı ben yazıyorum ve 14 sitenin hosting faturası benim masama geliyor.
Baştan bir itiraf. Performans vaka yazıları, blogların milisaniye uydurmaya başladığı türdür; ben burada yapmayacağım. Her değişikliğin öncesinde ve sonrasında laboratuvar ölçümü arşivlemedim; dolayısıyla bu yazıda "LCP 4,8 saniyeden 1,9'a indi" tarzı bir tablo bulamayacaksınız — yazsam kurgu olurdu. Yapabileceğim şey, jekcms'in gerçekten gemide taşıdığı her mekanizmayı alıp hangi skor metriğini neden oynattığını mekanik olarak anlatmak. 97 gerçek; kol başına milisaniyeler gerçek olmazdı.
Skoru üç sayı belirliyor
Lighthouse mobilde birkaç metriği tartar ama pratikte skor üç şeyle yaşar, üç şeyle ölür: Largest Contentful Paint (ana içerik ne kadar çabuk görünüyor), Cumulative Layout Shift (sayfa yüklenirken ne kadar zıplıyor) ve Total Blocking Time (JavaScript ana iş parçacığını ne kadar kilitliyor). Bu üçü yeşilse FCP ve Speed Index genelde peşlerinden gelir; çünkü örtüşen şeyleri ölçerler.
Aşağıdaki her teknik aslında tek bir sorunun cevabı: üçünden hangisini oynatıyor?
İlk yanıt: kritik CSS'i içeri göm, gerisini ertele
Düz bir stylesheet linki render-blocking'dir. Tarayıcı HTML'i indirir, linki görür ve CSS gelene kadar hiçbir şey çizmez. Hızlı bir masaüstü bağlantısında bunu fark etmezsiniz bile. PageSpeed'in simüle ettiği kısılmış mobil profilde ise bu tek bağımlılık zinciri ilk boyamayı kendi başına geriye iter.
jekcms zinciri üç hamlede kırıyor: ekranın üstü için gereken kritik CSS head içine gömülüyor, tam stylesheet render'ı bloklamadan preload ile yükleniyor, JavaScript defer ile erteleniyor. Temalarla gelen kalıp şu:
<style>/* kritik CSS, satır içi */</style>
<link rel="preload" href="/assets/css/style.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/assets/css/style.css"></noscript>
<script src="/assets/js/app.js" defer></script>Ne oynuyor: LCP, çünkü ilk boyama artık CSS için bir ağ turu beklemiyor. Ve TBT, çünkü ertelenen betikler parse işlemini kesmek yerine sonrasında koşuyor. jekcms temaları zaten az JavaScript taşır — küçük bir paketi ertelemek kolaydır. Bir tag-manager yığınını ertelemek başka bir spordur ve sizi ondan hiçbir CMS ayarı kurtaramaz.
Mobilde LCP'yi görseller belirler
İçerik sitesinde LCP elemanı neredeyse her zaman öne çıkan görseldir. jekcms her yüklemeyi dönüşüm hattından geçirir: görsel en fazla 1920px genişliğe indirilir, AVIF'e kodlanır ve yanına WebP fallback üretilir. Orijinal dosya asla servis edilmez — editör sıkıştırmayı unuttu diye ziyaretçiye fotoğraf makinesinden çıkmış megabaytlarca ham JPEG giden bir kod yolu yok. O "unuttu" senaryosu varsayımsal değil. Birden çok site ve yıllara yayılan yüklemelerde varsayılan hata modu tam olarak bu; hat da kimse hatırlamak zorunda kalmasın diye var.
Markup tarafında görseller iki formatlı picture elementi ve açık boyutlarla çıkıyor:
<picture>
<source srcset="/uploads/images/ornek.avif" type="image/avif">
<source srcset="/uploads/images/ornek.webp" type="image/webp">
<img src="/uploads/images/ornek.webp"
alt="Yazı gövdesinden ekran görüntüsü"
width="1200" height="800" loading="lazy">
</picture>Burada iki ayrı metrik birden yönetiliyor. AVIF ve WebP kaynakları LCP'yi oynatır: ekrandaki en büyük eleman daha az bayt taşır. width ve height nitelikleri ise CLS'yi oynatır: tarayıcı dosya gelmeden kutuyu ayırır, alttaki metin hiç zıplamaz. Ekran altındaki görseller loading="lazy" alır; hero bilerek almaz — kendi LCP elemanını lazy yüklemek klasik bir kendi ayağına sıkma vakasıdır.
Sunucu tarafı önbellek laboratuvar skoruna yansır mı?
Yansır; hem de herkesin unuttuğu metrik üzerinden: ilk bayta kadar geçen süre. LCP kronometresi ilk boyamada değil, navigasyonda başlar — sunucunuzun düşünerek geçirdiği her milisaniye LCP'nin içinde oturur. PHP worker'ınızın komşularla yarıştığı paylaşımlı hostingde, çoğu kişinin bakmak istemediği kısım da burasıdır.
jekcms üç önbellek katmanını üst üste koyar ki tipik bir istek hiç gerçek iş yapmasın. Sayfa önbelleği hazır HTML'i 300 saniyelik TTL ile servis eder. Altında veri ve sorgu önbellekleri PHP'ye düşen istekleri karşılar. OPcache de derlenmiş bytecode'u bellekte tutar; PHP her istekte kaynak dosyaları yeniden parse etmez. Önbellekten dönen bir istekte CMS aşağı yukarı hiçbir şey yapmaz — aynı yazıyı on bininci kez göstermek için doğru iş miktarı da tam olarak budur.
Ölçek bilgisi de vereyim ki "küçük sitede her şey hızlıdır" itirazı baştan düşsün: filodaki en büyük site 2.300'den fazla yazı taşıyor, on dört sitenin toplamı 5.500 yazıyı geçiyor. Önbellek katmanları tam da bu yüzden pazarlanabilir bir özellik değil, benim için hayatta kalma aracı. Kategori sayfaları, arşivler, etiketler — hepsi aynı üç katmandan geçiyor; yazı sayısı büyüdükçe fark hissedilir hale geliyor, çünkü önbelleğe düşmeyen her istek o büyüyen tablolarda sorgu demek.
Bir ameliyat izi paylaşayım. Deploy betiğimizin sonunda OPcache reset olmasının sebebi yaşanmışlık: bir keresinde düzeltmeyi gönderdik ve eski davranışın üretimde aynen sürdüğünü izledik — PHP, deploy öncesinden kalma bayat bytecode'u keyifle servis ediyordu. O günden beri sıra sabit: deploy, OPcache reset, sayfa önbelleği purge. 300 saniyelik TTL aynı zamanda emniyet supabı; purge unutulsa bile sayfa beş dakika içinde kendini toparlıyor.
HTML küçültme — listenin mütevazısı
jekcms üretim modunda HTML çıktısını bir output buffer filtresiyle küçültür: etiketler arası boşluklar daraltılır, yorumlar atılır, pre ve code bloklarının içi olduğu gibi korunur. Sıralamasını dürüstçe söyleyeyim: bu, yazıdaki en küçük kol. Daha küçük HTML ilk ağ turlarına yardım eder ve çalışma zamanında bedavadır; ama kimse markup küçülterek 70'ten 97'ye çıkmaz. Listede olması gerçek ve bedava olmasından — kahramanlığından değil.
Skorla hiç ilgisi olmayan AVIF tuzağı
Her şeyi AVIF'e çevirin; günün birinde Facebook'ta bir link paylaşacak ve boş bir kartla karşılaşacaksınız. Facebook da X de og:image için AVIF çözmüyor. jekcms'in hattı sosyal kart için ayrıca bir JPG/WebP kopya tutuyor: sayfa tarayıcıya AVIF servis ederken og:image etiketi crawler'ların gerçekten okuyabildiği bir formatı gösteriyor.
Bunun PageSpeed puanına etkisi iki yönde de sıfır. Yine de burada, çünkü aynı hattın parçası — ve AVIF'e tam gaz geçen herkes bu duvara çarpıyor, genellikle de herkesin gözü önünde.
Harita: hangi kol hangi metriği oynatıyor
- LCP — önbellek katmanları ile OPcache (sunucu hızlı yanıt verir), AVIF hero (en büyük eleman hafifler) ve satır içi kritik CSS (render stylesheet beklemez).
- CLS — her görselde açık width/height; artı, sonradan enjekte olup düzeni kaydıran widget taşımayan temalar.
- TBT — ertelenmiş ve az JavaScript. Bu bir teknikten çok perhiz.
Eksik olana dikkat edin: hangi kolun kaç milisaniye kazandırdığını yazmadım. Çünkü tek tek izole ölçmedim ve yazıyı kulağa makul gelen sayılarla süslemeyi reddediyorum. Yukarıdaki mekanizmalar bu metriklerin çalışma biçimi; 97 ise gerçek bir sitede hepsinin toplamı.
97'nin söylemediği şeyler
Laboratuvar skoru, simüle edilmiş bir cihazda sentetik bir koşudur. Gerçek ziyaretçiler gerçek ağlarda farklı bir şey görür ve aynı sayfa iki koşu arasında birkaç puan oynayabilir. Sayıyı kupa gibi değil, sağlık kontrolü gibi okuyun.
Son birkaç puan çoğu zaman CMS'e değil, üstüne eklediğiniz üçüncü taraf betiklere aittir: analitik, consent banner'ı, reklam kodu. jekcms'in ZeroTrack diye çerezsiz, yerleşik bir analitik eklentisi taşımasının bir nedeni de bu — dış istek yok, ana iş parçacığında içerikle yarışan üçüncü taraf paketi yok. Üstüne AdSense koyarsanız birkaç puanı geri verirsiniz. Bu bir performans başarısızlığı değil, ticari bir karardır — yeter ki bilerek verilsin.
Paylaşımlı hostingin gerçekçi olarak ne verdiğini merak ediyorsanız paylaşımlı hosting performans rehberi var; buradaki özelliklerin tamamı dokümantasyonda da anlatılıyor.
