Web sitesi açılış hızı nasıl ölçülür, nasıl iyileştirilir

Bir siteye girdiğinizde ekran birkaç saniye beyaz kalıyorsa, çoğu insan içeriğin ne olduğunu merak bile etmeden geri tuşuna basar. Bu davranışı hepimiz yapıyoruz. Yine de site sahiplerinin çoğu, kendi sitelerini ofisteki fiber bağlantıdan ve tarayıcı önbelleği doluyken açtığı için her şeyin yolunda olduğunu sanıyor.

Hız konusu son yıllarda gereğinden fazla teknik bir dile büründü. Oysa mesele basit: ziyaretçi tıkladıktan sonra ne kadar süre bekliyor, beklerken ekranda ne görüyor ve içerik geldiğinde ne kadar kararlı duruyor. Bu yazıda önce doğru ölçmeyi, sonra da gerçekten işe yarayan iyileştirmeleri sırayla anlatacağım.

Bir not düşeyim: hız bir teknik gösteri meselesi değil, ticari bir mesele. Reklam vererek gelen bir ziyaretçi sayfa açılmadan çıktığında o tıklamanın bedelini zaten ödemiş olursunuz. Mobil veri üzerinden, zayıf sinyalle gezen bir kullanıcı için ise iki saniyeyle altı saniye arasındaki fark, teklif alıp almaması arasındaki fark demek. Bu yüzden hızı tasarımın süsü değil, altyapısı olarak görmek gerekiyor.

Hız tek bir sayı değildir

"Sitem kaç saniyede açılıyor" sorusunun tek bir cevabı yok. Çünkü bir sayfanın yüklenmesi tek bir an değil, birbirini takip eden bir dizi olay. Google'ın Core Web Vitals adını verdiği ölçütler tam da bu yüzden var; kullanıcının deneyimini üç ayrı açıdan ölçüyorlar.

LCP – en büyük içeriğin görünme süresi

Sayfadaki en büyük görsel ya da metin bloğu ekranda ne zaman belirdi? Ziyaretçi için "sayfa açıldı" hissi genellikle bu ana denk gelir. İyi kabul edilen eşik 2,5 saniye. Kurumsal sitelerde bu değeri bozan şey neredeyse her zaman devasa bir kapak görselidir.

INP – etkileşime yanıt süresi

Menüye tıkladınız, açılması yarım saniye sürdü. Forma yazı yazdınız, harfler gecikmeli göründü. INP bu tepkisizliği ölçer. Arkada çalışan ağır JavaScript kodları ana sebebidir. 200 milisaniyenin altı iyi sayılır.

CLS – düzen kayması

Yazıyı okumaya başlıyorsunuz, üstte geç yüklenen bir reklam ya da görsel beliriyor ve metin aşağı kayıyor. Yanlış butona basıyorsunuz. CLS bu rahatsızlığı puanlar. 0,1'in altında tutmak gerekir.

Bunlara bir de TTFB'yi (sunucunun ilk baytı gönderme süresi) eklemek lazım. TTFB yüksekse diğer her şeyi optimize etseniz de bir yere varamazsınız, çünkü tarayıcı daha işe başlayamamıştır bile. TTFB'yi sayfanın başlangıç çizgisi gibi düşünün: çizgi geride başlıyorsa yarışı önden bitirme şansınız yok.

Ölçüm: laboratuvar verisi mi, saha verisi mi

Burada çoğu kişinin karıştırdığı bir ayrım var.

• Laboratuvar verisi: Lighthouse, GTmetrix, WebPageTest gibi araçların kontrollü bir ortamda yaptığı simülasyon. Tekrarlanabilir, sorunun kaynağını gösterir. Ama gerçek kullanıcıyı temsil etmez.
• Saha verisi: Gerçek ziyaretçilerin tarayıcılarından toplanan anonim veriler. PageSpeed Insights sayfasının üst kısmında ve Search Console'un Core Web Vitals raporunda görürsünüz. Asıl bakmanız gereken budur.

Pratikte şöyle ilerliyoruz: saha verisi hangi sayfa gruplarının sorunlu olduğunu söyler, laboratuvar verisi o sayfada neyin yavaşlattığını söyler. İkisini birlikte kullanmazsanız ya körlemesine optimize edersiniz ya da var olmayan bir sorunu kovalarsınız.

Hangi aracı ne için kullanmalı

Araç seçimini karmaşıklaştırmaya gerek yok. PageSpeed Insights hem saha hem laboratuvar verisini bir arada verdiği için ilk bakış noktasıdır. Tarayıcının kendi geliştirici araçlarındaki ağ sekmesi, hangi dosyanın kaç kilobayt olduğunu ve ne kadar beklettiğini en net gösteren yerdir; grafiklerden çok bu listeye bakmak yol açar. WebPageTest ise bağlantı hızını ve konumu seçerek test yapmanıza izin verir, yani "3G'de ne oluyor" sorusunun cevabını verir. Search Console ise tek tek sayfa değil, sayfa grupları bazında aylara yayılan eğilimi gösterir.

Ölçerken sık yapılan hatalar

• Sadece ana sayfayı test etmek. Ziyaretçilerin büyük kısmı arama sonuçlarından iç sayfalara giriyor. Ürün, hizmet ve blog sayfalarını da ölçün.
• Tek seferlik ölçüm. Sunucu yükü, ağ durumu, o anki trafik sonucu değiştirir. En az üç ölçümün ortasını alın.
• Masaüstü sekmesine bakmak. Trafiğin çoğunluğu mobil. Mobil skoru genellikle masaüstünden belirgin biçimde düşüktür ve gerçek olan odur.
• 100 puan takıntısı. Skor bir teşhis aracı, hedef değil. 90 ile 100 arasındaki farkı hiçbir ziyaretçi hissetmez; 40 ile 80 arasındaki farkı herkes hisseder.
• Önbelleği temizlemeden test etmek. Kendi sitenizi günde on kez açıyorsanız tarayıcınız dosyaların yarısını zaten saklamıştır. İlk kez gelen ziyaretçinin gördüğü tabloyu görmek için gizli sekme kullanın.

Yavaşlığın gerçek sebepleri

Yüzlerce sayfa inceledikten sonra insan aynı beş altı sorunu tekrar tekrar görüyor. Sıralayayım.

1. Optimize edilmemiş görseller

Açık ara birinci sebep. Telefonla çekilmiş 4 MB'lık bir fotoğrafın siteye olduğu gibi yüklenmesi, sonra da tarayıcıda küçültülerek gösterilmesi. Ziyaretçi 4 MB'ı indiriyor ama 300 piksellik bir alanda görüyor. Anasayfada döngüyle dönen beş kapak görseli varsa, kullanıcı hiçbirini görmeden onlarca megabaytı indirmeye başlamış olur.

2. Barındırma ve sunucu tarafı

Paylaşımlı, aşırı doldurulmuş sunucularda TTFB 1,5 saniyeyi bulabiliyor. Site kodu ne kadar temiz olursa olsun bu gecikme sabit bir vergi gibi her sayfaya ekleniyor. Biz bu yüzden paketlerimizde barındırmayı işin dışında bırakılan bir kalem olarak değil, teslimin parçası olarak veriyoruz; domain ve güncellemelerle birlikte dahil. Sonradan "sunucu bizim işimiz değildi" demek performans sorumluluğunu ortada bırakıyor.

Sunucu tarafında ayrıca güncel PHP sürümü, veritabanının bakımı ve sayfa önbelleğinin doğru kurulması var. Aynı site, aynı kodla, düzgün yapılandırılmış bir sunucuda gözle görülür biçimde daha hızlı açılır. Bu, kod yazmadan kazanılan en büyük paydır.

3. Eklenti ve tema şişkinliği

Hazır bir temanın üstüne on beş eklenti kurulduğunda, her biri kendi CSS ve JavaScript dosyasını sayfaya ekler. Tek bir iletişim formu için 200 KB kod yüklemek olağan hale geldi. Kullanılmayan eklentiyi pasif yapmak yetmez, kaldırmak gerekir.

4. Yazı tipleri

Üç farklı font ailesi, her birinin dört ağırlığı, hepsi dış sunucudan. Metin, fontlar inene kadar görünmüyor ya da geç gelen fontla birlikte satırlar kayıyor.

5. Üçüncü taraf betikleri

Canlı destek widget'ı, ısı haritası aracı, iki ayrı analiz kodu, sosyal medya beslemesi, gömülü harita ve gömülü video. Her biri kendi başına masum görünür; toplamı sayfanın ağırlığının yarısını oluşturur. Üstelik bu dosyaların hızı sizin kontrolünüzde değildir.

İyileştirme: nereden başlamalı

Sıralama önemli. En az emekle en çok kazandıran işlerden başlayın. Aynı gün içinde beş değişikliği birlikte yapıp sonra ölçerseniz, hangisinin işe yaradığını asla bilemezsiniz. Tek tek uygulayıp arada ölçmek daha yavaş ama daha öğretici bir yöntem.

Görselleri düzeltin

• Formatı WebP veya AVIF'e çevirin. Aynı görsel kalitesinde dosya boyutu genellikle yarıya iner.
• Görseli gösterileceği boyutta yükleyin. Sitede 800 piksel genişliğinde görünecek bir fotoğrafı 4000 piksel olarak koymayın.
• Ekranın altında kalan görsellere lazy loading uygulayın, ama LCP görseline uygulamayın; o tam tersine öncelikli yüklenmeli.
• Her görsele genişlik ve yükseklik değeri verin. Bu tek başına CLS sorunlarının büyük kısmını çözer.

Bu iş tek seferlik değil; sitenin içerik editörü yeni fotoğrafı ham haliyle yüklediğinde her şey başa döner. Teslimde yaptığımız panel eğitiminin en çok konuşulan konusu da genelde bu oluyor: görsel yüklemeden önce boyutlandırma alışkanlığı.

Önbellek ve dağıtım

Sayfa önbelleği, tarayıcı önbelleği ve gerekiyorsa CDN. Statik dosyalar için uzun önbellek süreleri tanımlayın. Ege dışına, hatta yurt dışına hitap eden bir siteniz varsa CDN'in katkısı ölçülebilir düzeyde olur; sadece yerel müşteriye hitap eden bir sitede öncelik listesinin altındadır.

Kodu hafifletin

• Kullanılmayan CSS ve JavaScript'i temizleyin.
• Kritik olmayan betikleri defer veya async ile erteleyin.
• Dosyaları sıkıştırın (Gzip/Brotli).
• Sayfanın ilk görünen kısmı için gereken stilleri öne alın.
• Aynı işi yapan iki kütüphaneyi birlikte taşımayın; slider, ikon seti ve animasyon kütüphanelerinde bu çok sık oluyor.

Yazı tiplerini disipline edin

İki aileyi geçmeyin, gereksiz ağırlıkları atın, fontları kendi sunucunuzdan servis edin ve font-display: swap kullanın ki metin beklemeden görünsün.

Üçüncü taraf araçlarını gözden geçirin

Her aracı tek tek sorgulayın: bu veriye son altı ayda kaç kez baktık? Bakmadıysanız kaldırın. Canlı destek widget'ını kullanıcı etkileşime geçtiğinde yükleyin. Gömülü videoyu doğrudan değil, önce kapak görseliyle gösterip tıklamada yükleyin. Haritayı da aynı mantıkla.

Yeni bir site yapılıyorsa

Var olan bir siteyi hızlandırmak, baştan hızlı kurmaktan her zaman daha zahmetlidir. Yeni bir projede tasarım aşamasında sorulacak birkaç soru sonradan günler kazandırır: anasayfada gerçekten dönen bir kapak alanına ihtiyaç var mı, kaç font ailesi kullanacağız, hangi analiz araçları en baştan planda olacak, görseller hangi ölçülerde hazırlanacak. Tasarımcı ve yazılımcı bu kararları birlikte verdiğinde performans sonradan yapıştırılan bir yama olmaktan çıkıyor.

Mobil uygulama tarafında durum

Performans sadece web sitesi meselesi değil. Uygulamalarda açılış süresi, liste kaydırma akıcılığı ve ağ isteklerinin yönetimi aynı ölçüde belirleyici. Flutter ile tek kod tabanı üzerinden geliştirdiğimizde iOS ve Android'de aynı performans iyileştirmesini iki ayrı yerde tekrar yapmak zorunda kalmıyoruz; bu da düzeltmelerin daha hızlı sahaya çıkması demek. Hizmetlerimiz içinde web ve mobil tarafı bu yüzden ayrı ayrı değil, aynı performans yaklaşımıyla ele alıyoruz.

Ölçmek bir kerelik iş değil

Site yayına girdiğinde hızlıdır. Altı ay sonra bir eklenti, üç yeni takip kodu ve yirmi büyük görsel eklenir; kimse fark etmez. Bu yüzden basit bir rutin öneriyorum:

• Ayda bir kez Search Console'daki Core Web Vitals raporuna bakın.
• Ana sayfa dışında en çok trafik alan üç sayfayı ayrıca ölçün.
• Yeni bir eklenti veya betik eklendiğinde öncesi-sonrası ölçüm yapın.
• Yılda bir kez kapsamlı temizlik yapın: kullanılmayan eklenti, eski medya dosyaları, ölü kod.

Bu rutini takvime yazmak, panelde yetkisi olan herkesin bildiği bir alışkanlığa dönüştürmek gerekiyor. Aksi halde hız, birinin canı sıkıldığında hatırladığı bir konu olarak kalıyor.

Gerçekçi beklenti

Hız, dönüşümü ve arama görünürlüğünü etkileyen faktörlerden biridir; tek faktör değildir. Yavaş bir site iyi bir teklifi batırabilir ama hızlı bir site kötü bir teklifi kurtarmaz. Önce sayfanın ne anlattığı, sonra ne kadar hızlı anlattığı önemli.

Yine de eşik değerlerin altına inmek çoğu sitede birkaç günlük işle mümkün. Genellikle sihirli bir çözüm değil, sıkıcı ama etkili beş altı düzeltme yeterli oluyor: görselleri küçültmek, gereksiz eklentiyi kaldırmak, fontları toplamak, önbelleği açmak, betikleri ertelemek.

Mevcut sitenizin nerede durduğunu merak ediyorsanız önce PageSpeed Insights'ta mobil sekmesinden bir bakın; çıkan tablo şaşırtıcıysa bize yazın, aynı iş günü içinde dönüş yapıp raporu birlikte okuyalım. Ölçümü yorumlamak, ölçümü almaktan daha kıymetli.