Site Hızı Neden Teknik Değil, Ticari Bir Sorundur

Bir sayfa yüklenmesi üç saniyeden uzun sürdüğünde, ziyaretçilerin büyük bir kısmı teklifinizi, portföyünüzü veya fiyatlandırmanızı görmeden siteyi terk eder. Yarım kalan her oturum, hiç gerçekleşmemiş bir görüşmedir. Hız genellikle "sonraya" bırakılabilecek bir mühendislik detayı olarak görülür, ama veriler nettir: daha hızlı siteler daha iyi dönüşüm sağlar, daha üst sıralarda yer alır ve reklam maliyeti daha düşüktür — çünkü reklam platformları yüksek kaliteli iniş sayfası deneyimlerini daha düşük tıklama başına maliyetlerle ödüllendirir.

Google bu gerçeği Core Web Vitals ile resmileştirdi: bir sayfanın gerçek bir insana ne kadar hızlı, duyarlı ve görsel olarak stabil hissettirdiğini ölçen üç metrikten oluşan bir set. Bunlar organik aramada doğrulanmış bir sıralama sinyali — yani performans çalışması artık SEO çalışmasıdır; bu iki disiplin artık birbirinden bağımsız planlanamaz.

Core Web Vitals Nedir?

Core Web Vitals, kullanıcı odaklı üç ölçümden oluşur: yükleme için Largest Contentful Paint (LCP), duyarlılık için Interaction to Next Paint (INP) ve görsel stabilite için Cumulative Layout Shift (CLS). Bunları eski hız metriklerinden ayıran şey, Google'ın bunları saha verisiyle değerlendirmesidir — hızlı bir sunucudan çalıştırılan bir laboratuvar testi değil, sitenizi ziyaret eden gerçek Chrome kullanıcılarından toplanan gerçek ölçümler. Puanlarınız, ziyaretçilerinizin gerçek cihazlarında ve gerçek bağlantılarında yaşadığı deneyimi yansıtır.

LCP: Largest Contentful Paint

LCP, en büyük görünür öğenin — genellikle bir hero görseli veya başlık — ekranda görünmesinin ne kadar sürdüğünü ölçer. Google'ın "iyi" eşiği 2,5 saniyedir. En yaygın suçlular; mobil cihazlara masaüstü çözünürlüğünde sunulan aşırı büyük görseller, sayfa head'inde yüklenen render'ı engelleyen script'ler ve yavaş sunucu yanıt süreleridir. Pratikte, hero görsellerini WebP veya AVIF gibi modern formatlara dönüştürmek, hero görseline açık öncelik tanımlamak ve bir CDN kullanmak, tek bir satır uygulama kodu değiştirmeden LCP sorunlarının büyük kısmını çözer.

INP: FID'nin Yerini Alan Metrik

Mart 2024'te Interaction to Next Paint, resmi olarak First Input Delay'in yerini bir Core Web Vital olarak aldı — ve FID'yi rahatça geçen birçok site aniden başarısız olmaya başladı. INP daha katıdır: yalnızca ilk etkileşimin gecikmesini ölçmek yerine, menü dokunuşlarından form tıklamalarına kadar ziyaret boyunca gerçekleşen tüm etkileşimlerin duyarlılığını değerlendirir. "İyi" bir INP 200 milisaniyenin altındadır. Ağır üçüncü taraf script'leriyle yüklü siteler — sohbet widget'ları, eski piksellerle dolu etiket yöneticileri, oturum kaydediciler — burada genellikle başarısız olur. Artık kullanmadığınız script'leri denetleyip kaldırmak, çoğu zaman en yüksek etkiye sahip tek düzeltmedir.

CLS: Cumulative Layout Shift

CLS, sayfanın yüklenirken ne kadar zıpladığını ölçer — bir düğmeye dokunmaya çalışırken bir reklamın veya geç yüklenen bir görselin onu ekranda aşağı itmesi gibi can sıkıcı anları. İyi bir puan 0,1'in altındadır. Layout shift neredeyse her zaman boyutları tanımlanmamış görsellerden, render sonrası devreye giren web fontlarından veya mevcut içeriğin üzerine eklenen banner'lardan kaynaklanır. Düzeltmeler çoğunlukla basittir: her görsel ve gömülü öğe için yer ayırın, birincil fontunuzu önceden yükleyin ve kullanıcının zaten okuduğu içeriğin üzerine asla yeni içerik eklemeyin.

Puanlarınızı Nasıl Ölçersiniz

PageSpeed Insights ile başlayın; hem laboratuvar sonuçlarını hem de — sitenizde yeterli trafik varsa — Chrome UX Report'tan gelen saha verisini gösterir. Ardından Google Search Console'daki Core Web Vitals raporunu kontrol edin; bu rapor URL'lerinizi duruma göre gruplandırarak bir sorunun tek bir şablonu mu yoksa tüm siteyi mi etkilediğini görmenizi sağlar. Bu gruplandırma tanı için bir kısayoldur: eğer her blog yazısı LCP'de başarısız oluyorsa ama ürün sayfaları geçiyorsa, yüzlerce ayrı sayfa sorunu değil, şablon düzeyinde bir sorun arıyorsunuz demektir.

Çoğu Sitenin Kaçırdığı Hızlı Kazanımlar

Yeniden bir yapım işine girmeden önce temelleri gözden geçirin: her görseli gerçekten görüntülendiği boyutlara sıkıştırıp yeniden boyutlandırın; katlanma çizgisinin altındaki her şeyi lazy-load yapın ama hero görseline asla dokunmayın; kritik fontları kendi sunucunuzdan servis edin veya önceden yükleyin; gerekli olmayan JavaScript'i erteleyin; ve CDN seviyesinde agresif bir şekilde önbellekleme yapın. Deneyimlerimize göre bu göze çarpmayan adımlar yükleme sürelerini rutin olarak yarı yarıya düşürür. Ancak bunlar tükendikten sonra mimari değişiklikleri konuşmak mantıklı olur.

Performans Bir Tasarım Kararıdır

En hızlı siteler, projenin sonunda yapılan kahramanca bir optimizasyon sayesinde hızlı değildir — performans, ilk wireframe'den itibaren bir kısıt olduğu için hızlıdırlar. Bir video arka plan yerine hafif bir layout seçmek, animasyonu önemli öğelerle sınırlamak ve her üçüncü taraf gömme öğesini sorgulamak, doğrudan gelir sonuçları olan tasarım kararlarıdır. Hız bütçeleri QA kontrol listesinde değil, tasarım brief'inde yer almalıdır.

Başlarken

Bu hafta önemli sayfalarınızı PageSpeed Insights'tan geçirin ve üç metrikten hangisinin önce başarısız olduğunu not edin — bu size gerçek darboğazın nerede olduğunu gösterir. Eğer düzeltmeler görseller ve script'lerin ötesine, sitenin nasıl inşa edildiğine kadar uzanıyorsa, web tasarım ve geliştirme ekibimiz, performans bütçelerini ilk günden itibaren sitenin içine gömerek inşa eder — böylece Core Web Vitals'ı geçmek hedef değil, başlangıç noktası olur.