PHP siteleri için Core Web Vitals: LCP, INP ve CLS nasıl düzeltilir?

PHP siteleri için Core Web Vitals yalnızca ön uçla ilgili bir konu değildir. Yavaş bir PHP sayfası, yalnızca HTML üretmek için bir saniye harcayabilir ve hiçbir görüntü optimizasyonu bunu telafi edemez. Aynı zamanda, 1,5 MB'lık bir kahraman resminin en büyük boyayı engellemesi durumunda çok hızlı bir sunucunun faydası olmaz. Kendi PHP sitelerimizde (integrono.com, nginx ve Cloudflare arkasında PHP-FPM çalıştırır) ve istemci projelerinde her iki tarafa da şu şekilde yaklaşıyoruz.

Core Web Vitals neyi ölçer?

• LCP ( Largest Contentful Paint): görünür en büyük öğe (genellikle bir kahraman görüntüsü veya bir başlık bloğu) oluşturulduğunda. İyi 2,5 saniye veya daha azdır.
• INP ( Interaction to Next Paint): Tüm ziyaret boyunca sayfanın tıklamalar, dokunmalar ve tuşlara basıldıktan sonra görsel olarak ne kadar hızlı yanıt verdiği. İyi 200 ms veya daha azdır.
• CLS ( Cumulative Layout Shift): yükleme sırasında içeriğin ne kadarının atladığı. İyi 0,1 veya daha azdır.

Google bunları, mobil ve masaüstü için ayrı ayrı, yüzde 75'lik dilimdeki gerçek Chrome kullanıcılarından elde edilen saha verileri üzerinden değerlendiriyor. Bu, yavaş bir şablonun veya yavaş bir ülkenin tüm grubu başarısızlığa uğratabileceği anlamına gelir. Lighthouse gibi laboratuvar araçları nihai puan için değil, hata ayıklama içindir.

Adım 1. Doğru şekilde ölçün

1. Hangi URL gruplarının hangi ölçüme göre başarısız olduğunu görmek için Google Search Console Core Web Vitals raporunu açın.
2. Başarısız olan her gruptan bir URL için PageSpeed Insights kontrol edin. En üstteki "alan verisi" bloğu önemli olandır; Aşağıdaki Lighthouse bloğu bunun nedenini açıklayan bir laboratuvar testidir.
3. Tipik bir mobil deneyimi yeniden oluşturmak için Chrome DevTools'taki Performans panelini CPU 4x yavaşlama ve "Yavaş 4G" ile kullanın.
4. Sürekli izleme için web-vitals JavaScript kitaplığıyla gerçek kullanıcı verilerini toplayın ve analizlerinize gönderin.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

2. Adım. Önce sunucu yanıt süresini ( TTFB) düzeltin

LCP ilk bayt gelmeden önceki süreyi içerir. HTML'nizin oluşturulması 800 ms sürüyorsa, bütçenin üçte birini zaten harcamışsınız demektir. PHP sitelerinde olağan kaldıraçlar şunlardır:

• OPcache etkinleştirin ve tüm komut dosyalarını tutacak kadar büyük olduğundan emin olun. Bu olmadan PHP her istek üzerine dosyaları yeniden derler.
• PHP-FPM ayarlayın. Çok az sayıda çalışan istekleri sıraya koyuyor, çok fazla bellek tükeniyor. "Dinleme kuyruğu" ve "ulaşılan maksimum çocuk sayısı" için PHP-FPM durum sayfasını izleyin.
• Anonim ziyaretçiler için tüm sayfaları (nginx fastcgi_cache, bir Laravel yanıt önbelleği veya Cloudflare önbellek kuralları) önbelleğe alın ve Redis ile parçaları veya sorgu sonuçlarını önbelleğe alın.
• Yavaş sorguları düzeltin. Yavaş sorgu günlüğünü açın, N+1 kalıplarını arayın ve dizinler ekleyin. 120 sorgu çalıştıran bir sayfa, PHP sürümünden bağımsız olarak yavaştır.
• PHP'yi güncel tutun. Daha yeni PHP sürümleri daha hızlıdır ve daha az bellek kullanır.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

pm.max_children değerini gerçek bellekten ayarlayın: PHP'ye verebileceğiniz belleği, çalışan sürecin ortalama boyutuna bölün (ps ile kontrol edin). validate_timestamps=0 ile her dağıtımdan sonra PHP-FPM yeniden yüklemeyi unutmayın, aksi takdirde eski kod bellekte kalır.

Web sunucusu düzeyinde HTTP/2 veya HTTP/3, Brotli veya gzip'i ve statik dosyalar için uzun ömürlü önbelleğe alma başlıklarını etkinleştirin:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Sürümlendirilmiş dosya adları veya dosyanın değiştirilme zamanına dayalı bir ?v= sorgusu kullanın, böylece "değişmez" hiçbir zaman eski varlıklar sunmaz.

3. Adım. LCP öğesini düzeltin

PageSpeed Insights veya DevTools Performans panelinde LCP öğesini bulun. Çoğu içerik sayfasında bu bir kahraman görselidir. Daha sonra:

• Tembel yükleme yapmayın. LCP görüntüsündeki loading="lazy" bunu geciktirir. Bunun yerine fetchpriority="high" kullanın.
• Doğru boyutta servis yapın. 900 piksellik bir yuva için 2400 piksellik bir görüntü bayt israfına neden olur. srcset ve sizes kullanın.
• WebP veya AVIF kullanın. Tipik tasarruf, benzer kalitede JPEG'e göre yüzde 30 ila 60 arasındadır.
• Zincirlerden kaçının. CSS arka planı aracılığıyla ayarlanan veya JavaScript tarafından enjekte edilen bir görüntü geç keşfedilir. Bunu HTML'ye <img> olarak koyun.
• LCP bağlı olduğu ön bağlantı veya kendi kendine barındırılan üçüncü taraf kaynaklar (yazı tipleri, görüntü CDN'si).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Makalenin bu blog kullanımında kapsadığı kalıp budur: iki WebP boyutu, belirgin boyutlar ve kahraman için yüksek getirme önceliği.

4. Adım. Düzen vardiyalarını kaldırın ( CLS)

• Tarayıcının alanı ayırması için resimlerde, videolarda ve iframe'lerde her zaman width ve height (veya CSS'de aspect-ratio) ayarlayın.
• Banner'lar, çerez bildirimleri ve reklamlar için yer ayırın. Yüklendikten sonra içeriği aşağı itmek yerine bunları sabit minimum yüksekliğe sahip bir kaba yerleştirin.
• Yazı tipleri: font-display: swap veya optional kullanın, ana yazı tipi dosyasını önceden yükleyin ve alt kümesine koyun. Benzer ölçümlere sahip bir yedek yazı tipi seçin.
• Kullanıcı tetiklemediği sürece mevcut içeriğin üzerine içerik enjekte etmeyin.
• Düzeni değiştiren özelliklerle (top, height) değil , transform ve opacity ile canlandırın.

Adım 5. INP geliştirin: ana başlıkta daha az JavaScript

INP en yeni ölçümdür ve sunucu bunu doğrudan etkilemediğinden PHP geliştiricilerinin ihmal ettiği bir ölçümdür. Bunun nedenleri tarayıcıdadır: büyük paketlerden gelen uzun görevler, ağır üçüncü taraf komut dosyaları (analiz, sohbet widget'ları, etiket yöneticileri) ve eşzamanlı olarak çok fazla iş yapan işleyiciler.

• Üçüncü taraf komut dosyalarını denetleyin. Kimsenin kullanmadığını kaldırın, geri kalanını defer veya ilk etkileşimden sonra yükleyin.
• Uzun görevleri bölün. requestIdleCallback, setTimeout veya Scheduler API ile işi parçalara ayırın; ağır hesaplamaları bir Web Worker taşıyın.
• DOM'u küçük tutun. Binlerce düğüm her güncellemeyi yavaşlatır.
• Döngülerdeki zorunlu eşzamanlı düzenlerden kaçının (düzen özelliklerini dönüşümlü olarak okuyup yazmak).
• Yavaş çalışmaya başlamadan önce anında geri bildirim (basılmış durum veya döndürücü) gösterin.

6. Adım. Dağıtım sürecinizde onu koruyun

Performans yavaş yavaş geriliyor: yeni bir etiket, daha ağır bir kahraman, ana sayfada ekstra bir sorgu. En önemli beş şablonunuz için Lighthouse CI veya planlı bir PageSpeed API kontrolü ekleyin, bütçeleri ( LCP, toplam JS boyutu, görüntü ağırlığı) belirleyin ve bunlar aşıldığında uyarı verin. Her sürümden önce ve sonra TTFB karşılaştırın; atlarsa bunun nedeni neredeyse her zaman bir sorgu veya artık isabet etmeyen bir önbellektir.

Gerçekçi bir iş düzeni

1. Alan verilerini ölçün ve arızalı URL gruplarını belirleyin.
2. OPcache etkinleştirin, PHP-FPM ayarlarını gözden geçirin, anonim trafik için tam sayfa önbelleğe alma ekleyin.
3. Kahraman görsellerini düzeltin: format, boyut, öncelik, boyutlar.
4. Geç yüklenen her şey için yer ayırın.
5. JavaScript'i azaltın ve erteleyin; kullanılmayan üçüncü tarafları kaldırın.
6. Saha verileri değişen bir pencere olduğundan 28 gün sonra yeniden ölçün.

İyileştirmelerin Search Console kademeli olarak görünmesini bekleyebilirsiniz: Rapor yaklaşık olarak son 28 güne ait verileri kullanır, dolayısıyla bugün gönderilen bir düzeltme yalnızca yaklaşık bir ay sonra tamamen görünür hale gelir.

Nasıl yardımcı olabiliriz?

Teknik SEO katılımının bir parçası olarak ve tek seferlik ayarlama olarak PHP ve Laravel projelerinde performans çalışmaları yapıyoruz: önbelleğe alma, sorgular, resimler ve kodla gönderilen ön uç düzeltmeleri. Yukarıdaki değişikliklerden hangisinin sitenizde işe yarayacağını bilmek istiyorsanız, danışmanlık veya sunucu analizi randevusu alın. Tarama ve dizine eklemeyle ilgili daha geniş kontrol listesi için teknik SEO denetim kontrol listemizi okuyun.