Performans tartışması çoğu projede yayına çıktıktan sonra başlar. Oysa hız, sonradan eklenen bir optimizasyon katmanı değil; mimari kararların doğal sonucudur. Hangi verinin sunucuda üretildiği, hangi kütüphanenin tarayıcıya gönderildiği ve görsellerin nasıl servis edildiği ilk günden belirlenir.
Google'ın ölçtüğü üç sinyal
| Metrik | Ne ölçer | Google'ın 'iyi' eşiği |
|---|---|---|
| LCP | En büyük içerik öğesinin görünme süresi | 2,5 sn ve altı |
| INP | Etkileşime verilen yanıt süresi | 200 ms ve altı |
| CLS | Sayfadaki beklenmedik kayma | 0,1 ve altı |
Eşikler Google'ın Core Web Vitals dokümantasyonunda tanımlanır ve gerçek kullanıcı verisinden ölçülür. Yani laboratuvar testinde iyi görünen bir sayfa, yavaş bağlantıdaki gerçek kullanıcılar için hâlâ kötü olabilir.
Pratikte en çok fark yaratan dört karar
- Sunucu tarafında render: ilk anlamlı içeriği JavaScript indirilmeden göstermek LCP'yi doğrudan düşürür.
- Görsel disiplini: doğru boyut, modern format ve ekran dışı görseller için lazy loading.
- Yazı tipi stratejisi: font dosyalarını sınırlı tutmak ve metnin font gelene kadar görünür kalmasını sağlamak.
- Üçüncü parti kod: her eklenen script hem indirme hem de ana iş parçacığı maliyeti demektir; gerekmeyeni kaldırmak en ucuz optimizasyondur.
Ölçmeden iyileştirme yapmayın
Optimizasyona tarayıcının kendi araçlarıyla (Lighthouse, Performance paneli) bir taban ölçüm alarak başlayın. Aksi halde iyileştirme hissi ile gerçek kazanç karışır. Ölçüm sonrası tek seferde tek değişiklik yapmak, hangi kararın işe yaradığını görünür kılar.
Hızlı site, az kod gönderen sitedir. Geri kalan her teknik önlem bu ilkenin türevidir.