Site hızı nasıl artırılır: Core Web Vitals için öncelik sırası

“Sitem yavaş” cümlesi tek başına bir teşhis değil. Yavaşlığın üç ayrı türü var ve üçü farklı işlerle çözülüyor. Yanlış olanı optimize etmek, hafta harcayıp hiçbir şeyi değiştirmemek demek.

Önce eşikler

Google’ın Core Web Vitals metrikleri üç tane. “İyi” sayılmak için ziyaretlerin %75’inde eşiğin altında kalmanız gerekiyor — ortalamanız değil, dağılımınız ölçülüyor. Mobil ve masaüstü ayrı değerlendiriliyor.

Metrik	Ne ölçer	İyi eşiği
LCP — Largest Contentful Paint	En büyük içeriğin ekrana gelme süresi	2,5 sn altı
INP — Interaction to Next Paint	Tıklamaya verilen yanıtın gecikmesi	200 ms altı
CLS — Cumulative Layout Shift	Sayfanın okurken zıplaması	0,1 altı

Bugün en sık başarısız olunan metrik INP: sitelerin yaklaşık %43’ü 200 ms eşiğini geçemiyor. LCP’ye harcanan mesai kadarını INP’ye harcayan çok az ekip var, oysa kaybın büyüğü orada.

Laboratuvar değil, alan verisi

En yaygın hata: Lighthouse skorunu hedef sanmak.

Lighthouse laboratuvar verisidir — tek bir cihazda, tek bir bağlantıda, tek seferlik ölçüm. Google’ın sıralamada kullandığı ise alan verisi: gerçek kullanıcıların gerçek cihazlarında toplanan CrUX kayıtları.

Lighthouse’ta 98 alıp alan verisinde kalmak son derece mümkün. Laboratuvar hızlı bir bilgisayarda ölçer; kullanıcılarınızın yarısı üç yaşında bir Android telefonda ve mobil veriyle geziyordur.

Kullanım biçimi şu: alan verisi neyin bozuk olduğunu söyler, laboratuvar neden bozuk olduğunu. Önce Search Console’daki Core Web Vitals raporuna bakın, sorunlu şablonu bulun, sonra o sayfayı Lighthouse ile açın.

LCP: en büyük görselin hikâyesi

LCP’yi neredeyse her zaman tek bir öğe belirler ve bu genelde kahraman görselidir. Sırayla:

1. LCP öğesini bulun. Tahmin etmeyin; Lighthouse doğrudan söyler.
2. O öğeyi tembel yüklemeyin. loading="lazy" ekranın üstündeki görsele konursa LCP’yi kendi elinizle geciktirmiş olursunuz. Onun yerine fetchpriority="high" verin.
3. Modern format ve doğru boyut. AVIF veya WebP, birden fazla genişlik ve doğru sizes. 2000 piksel genişliğinde bir görseli 400 piksellik alana koymak, ziyaretçinin veri paketinden çalar.
4. Sunucu yanıt süresini kısaltın. Belge 800 ms’de dönüyorsa görseli sıkıştırmanın anlamı yok. Statik üretim ve CDN bu adımı çoğu zaman tek başına çözer.
5. Yazı tiplerini engelleyici olmaktan çıkarın. font-display: swap ve kritik yüzler için preload.

INP: asıl kayıp burada

INP, kullanıcı bir şeye dokunduktan sonra ekranın değişmesine kadar geçen süreyi ölçer. Kötü INP’nin sebebi neredeyse her zaman ana iş parçacığını meşgul eden JavaScript’tir.

Yapılacaklar:

• Kullanılmayan JavaScript’i silin. En etkili müdahale bu ve en az yapılanı. Bir tarih kütüphanesi için 90 KB taşımak, üç satır Intl kodu varken savunulamaz.
• Üçüncü taraf betiklerini sayın. Analitik, ısı haritası, sohbet widget’ı, reklam pikselleri, A/B test aracı. Her biri ana iş parçacığında sıra bekler. Çoğu sitede INP’yi tek başına bozan şey budur.
• Uzun görevleri bölün. 50 ms’yi aşan her görev, o an gelen tıklamayı bekletir.
• Yanıtı işten ayırın. Tıklamada önce görsel geri bildirimi verin, ağır hesabı sonraya bırakın. Kullanıcı 200 ms içinde bir şey görmelidir.

Sohbet widget’ını ana sayfadan kaldırmak, altı saatlik kod optimizasyonundan daha çok kazandırabilir. Önce ölçün.

CLS: en kolay kazanç

CLS genelde üç sebepten bozulur ve üçünün de çözümü basittir:

• Boyutu belirtilmemiş görseller. width ve height verin; tarayıcı yeri baştan ayırsın.
• Sonradan yüklenen yazı tipi. Yedek font ile asıl font arasındaki metrik farkı satırları kaydırır. size-adjust ve yakın metrikli bir yedek yığın bunu kapatır.
• Sonradan enjekte edilen içerik. Çerez bandı, duyuru şeridi, reklam alanı. Yer baştan ayrılmalı.

CLS’yi düzeltmek genellikle bir günlük iştir ve üç metrikten en kolay kazanılanıdır.

Sıralama etkisi hakkında dürüst olmak

Core Web Vitals bir sıralama sinyalidir, ama küçük bir sinyaldir. Alakasız içerikle dolu hızlı bir site, alakalı içerikle dolu yavaş bir sitenin önüne geçmez.

Hızın asıl getirisi sıralamada değil, dönüşümde. Sayfa geç açıldığında ziyaretçi geri döner; bu, sıralama tablosunda değil ciro tablosunda görünür. Hızı bir SEO işi olarak değil, satın alma yolundaki bir sürtünme olarak ele alın — o zaman hangi sayfayı önce düzelteceğiniz de netleşir.

Kısa yol haritası

1. Search Console → Core Web Vitals → başarısız şablonu bul.
2. O sayfayı Lighthouse ile aç, LCP öğesini tespit et.
3. LCP öğesinin tembel yüklenmediğinden emin ol, formatı ve boyutu düzelt.
4. Üçüncü taraf betiklerini listele, işe yaramayanı sil.
5. Görsellere ve enjekte edilen alanlara boyut ver.
6. Dört hafta bekle — alan verisi gerçek kullanıcıdan toplandığı için anında değişmez.