Bir perakende projesinde ürün sayfalarının LCP değeri 3,4 saniyeydi. Yedi haftalık bir çalışmayla bunu 0,9 saniyeye indirdik. İşte sırasıyla ne yaptığımız ve hangi adımın ne kadar katkı sağladığı.
Önce ölçüm
Laboratuvar testleri (Lighthouse) yanıltıcı olabilir; gerçek kullanıcı verisi (RUM) esastır. Sahadaki p75 değerine bakın — kullanıcıların dörtte üçünün deneyimi budur ve Google'ın değerlendirdiği de odur.
1. Sunucu yanıt süresi
LCP'nin görünmeyen bileşeni TTFB'dir. Ürün sayfaları her istekte veritabanından üretiliyordu. Statik üretime geçip veri değiştiğinde yeniden ürettik; TTFB 780 ms'den 60 ms'ye indi.
Bu tek adım toplam kazancın yaklaşık yarısını sağladı.
2. Görsel stratejisi
Ürün görselleri optimize edilmemiş JPEG'lerdi ve hepsi aynı boyutta sunuluyordu.
- Tüm görseller WebP'ye çevrildi.
- Ekran boyutuna göre varyantlar üretildi (
srcset). - Hero görseline
fetchpriority="high"verildi. - Görsellere genişlik/yükseklik eklendi — CLS 0,18'den 0,01'e düştü.
- Alt kısımdaki görseller tembel yüklemeye alındı.
3. JavaScript bütçesi
Sayfa başına 480 KB JavaScript vardı; bunun önemli bir kısmı üçüncü taraf betikleriydi. 170 KB'lık bir bütçe koyduk ve derleme hattında bu bütçeyi aşan sürümleri engelledik.
Analitik ve sohbet widget'ı gibi betikleri etkileşim sonrasına erteledik. INP değeri de bu adımda belirgin biçimde iyileşti.
4. Font yükleme
Özel fontlar font-display: swap olmadan yükleniyordu; metin görünmeden önce boş kalıyordu. Swap ve ön yükleme ekledik, kullanılmayan font ağırlıklarını kaldırdık.
5. Uç önbellek
Statik varlıkları ve HTML'i kullanıcıya en yakın uç noktadan sunmaya başladık. Türkiye dışından gelen trafikte fark özellikle belirgindi.
Sonuç
| Metrik | Önce | Sonra |
|---|---|---|
| LCP (p75) | 3,4 sn | 0,9 sn |
| CLS | 0,18 | 0,01 |
| TTFB | 780 ms | 60 ms |
| JS boyutu | 480 KB | 164 KB |
Kalıcı olması için
Performans bir proje değil, sürekli bir disiplin. Bütçeleri derleme hattına koyun ve saha verisini haftalık izleyin. Aksi halde altı ay içinde eski değerlere dönersiniz.
