Web sitesi hızı nasıl ölçülür ve nasıl iyileştirilir?

"Sitem yavaş mı?" sorusunun cevabı hissiyatla verilemez. Kendi sitenizi kendi telefonunuzdan açtığınızda hızlı görünür: sayfa büyük ihtimalle tarayıcınızın önbelleğinde durur, alan adının IP karşılığı çözülmüştür ve siz bağlantınızın iyi olduğu bir yerdesinizdir. Ziyaretçiniz aynı sayfayı ilk kez, dışarıda, hattın zayıf çektiği bir noktada açıyor. İkisi aynı sayfanın ölçümü değil.

Bu yazıda hızın nasıl ölçüldüğünü, ölçüm sonucunun nasıl okunduğunu ve yavaşlığın gerçek sebeplerinin ne olduğunu anlatıyoruz. Anlatılan işlerin çoğunu dışarıdan destek almadan kendiniz yapabilirsiniz; hangilerinin geliştirici gerektirdiğini de ayrıca yazdık.

Hız neden konuşuluyor

İki ayrı sebep var ve bunlar sık karıştırılıyor.

Birincisi ziyaretçi tarafı: sayfa geç açıldığında insanlar beklemeden geri dönüyor. Bu kayıp özellikle reklamla gelen trafikte can yakıyor, çünkü orada tıklama başına ödeme yapıyorsunuz. Sayfa açılmadan çıkan kişi için de o parayı ödemiş oluyorsunuz.

İkincisi arama tarafı: Google, Core Web Vitals ölçülerini sayfa deneyimi sinyalleri arasında kullandığını açıkça söylüyor. Ancak beklentiyi doğru kurmak gerekiyor. Hız tek başına sizi üst sıraya çıkarmaz. Arama niyetine daha iyi cevap veren yavaş bir sayfa, alakasız hızlı bir sayfayı geçer. Hız, diğer her şey yaklaşık eşitken devreye giren bir ayırt edici gibi çalışıyor. Düzeltmeye değer, ama tek başına bir SEO planı değil. Sıralama konusunda kimsenin garanti veremeyeceğini de ekleyelim: Google sıralama kriterlerini açıklamıyor.

Üç ölçü ve gerçekte ne anlattıkları

Core Web Vitals üç değerden oluşuyor. Adları teknik, anlattıkları şey son derece somut.

LCP — sayfanın asıl içeriği ne zaman göründü

Largest Contentful Paint. Ekranın ilk görünen alanındaki en büyük öğenin (genellikle üstteki büyük görsel veya büyük başlık bloğu) boyanma anını ölçüyor.

Ziyaretçi için karşılığı "sayfa açıldı" hissinin oluştuğu andır. Google'ın iyi kabul ettiği eşik 2,5 saniyenin altı; 4 saniyenin üstü kötü sayılıyor.

LCP çoğu sitede görsel kaynaklı olur. Sayfanın en üstündeki fotoğraf birkaç megabaytsa LCP'yi tek başına o belirler. İkinci sık sebep sunucunun ilk baytı geç göndermesidir; o durumda görseli sıkıştırmak sınırlı fayda verir.

CLS — sayfa okurken yerinden oynadı mı

Cumulative Layout Shift. Sayfa yüklenirken içeriğin kaymasını ölçüyor. Yazıyı okumaya başlıyorsunuz, üstte bir öğe yükleniyor, metin aşağı kayıyor. Ya da butona basacakken buton yer değiştiriyor ve yanlış hedefe tıklıyorsunuz.

İyi eşik 0,1'in altı. Bu değeri bozan tipik iki şey var: ölçüsü belirtilmemiş görseller ve sonradan yüklenip yer kaplayan öğeler — çerez bandı, reklam alanı, geç gelen yazı tipi, kampanya duyuru şeridi.

CLS genellikle düzeltmesi en ucuz metriktir. Görsel etiketlerine genişlik ve yükseklik yazmak, sonradan gelen öğelere baştan yer ayırmak çoğu zaman yeter.

INP — tıklayınca cevap veriyor mu

Interaction to Next Paint. 2024 yılında FID'in yerine geçti ve ondan daha zorlu bir ölçü: tek bir ilk etkileşimi değil, ziyaret boyunca yapılan etkileşimlerin gecikmesini topluca değerlendiriyor.

Menüye bastınız, menü yarım saniye sonra açıldı. Forma yazı yazıyorsunuz, harfler geriden geliyor. INP'nin yakaladığı his bu. İyi eşik 200 milisaniyenin altı.

INP kötüyse sebep neredeyse her zaman JavaScript. Tarayıcı ana iş parçacığında uzun süren kod çalıştırıyor ve tıklamanıza bakacak boşluk bulamıyor. Bol eklentili sitelerde en sık bozulan metrik budur ve görsel sıkıştırmak bu metriği düzeltmez.

Lab verisi ve saha verisi aynı şeyi söylemez

Ölçüm sonuçlarını okurken en çok kafa karıştıran nokta burası.

Lab verisi, sayfanın kontrollü bir ortamda simüle edilerek açılmasıdır. Lighthouse ve PageSpeed Insights'ın alt bölümündeki puan buradan gelir. Belirli bir cihaz gücü ve belirli bir ağ gecikmesi varsayılır, sayfa bir kez açılır, ölçüm yapılır.

• Avantajı: tekrarlanabilir. Bir düzeltme yaptınız, tekrar ölçtünüz, farkı görürsünüz.
• Dezavantajı: sizin ziyaretçinizi temsil etmez. Simüle edilen koşul kitlenizin gerçek koşulundan yavaş da olabilir hızlı da.

Saha verisi, Chrome kullanan ve veri paylaşımına açık gerçek ziyaretçilerden toplanan ölçümdür. PageSpeed Insights'ın en üstündeki bölüm ve Search Console'daki Core Web Vitals raporu bunu gösterir; son 28 günün birikimidir.

• Avantajı: gerçektir. Ziyaretçinizin gerçek telefonunda olan şeyi anlatır.
• Dezavantajı: gecikmelidir. Bugün yaptığınız düzeltme raporda haftalar sonra görünür. Trafiği az olan adreslerde yeterli örnek toplanamadığı için sayfa bazında veri hiç çıkmayabilir.

Pratik kural: düzeltme yaparken lab verisine, karar verirken saha verisine bakın. Lab puanı birkaç birim düştü diye telaşlanmayın. Tersi de geçerli: lab puanı 95 ama saha verisi kötüyse gerçek ziyaretçinizde çözülmemiş bir şey var demektir.

Hangi araca ne zaman bakılır

PageSpeed Insights

Ücretsiz ve giriş gerektirmiyor. Adresi yazıp ölçüyorsunuz. Okurken şunlara dikkat edin:

• Mobil sekmesini açın. Masaüstü sekmesine bakıp rahatlamak yaygın bir hata.
• Üstte saha verisi bölümü çıkıyorsa önce oradaki renk kodlarına bakın; alttaki puan ikinci sıradadır.
• Alttaki "Fırsatlar" ve "Tanılama" listelerini açın. Puanın kendisinden çok bu liste iş görür: hangi dosyanın kaç kilobayt olduğunu ve ne kadar geciktirdiğini kalem kalem yazar.
• Ölçtüğünüz adresin tam hali önemli. Yönlendirmeye giren bir adres (http hali, www'suz hali ya da sondaki eğik çizgi farkı) ölçüme fazladan bir tur ekler. Ziyaretçinin ulaştığı son adresi ölçün.

Search Console'daki Core Web Vitals raporu

Search Console hesabınız yoksa açın; ücretsiz ve bu rapor için şart. Rapor sitenizin tüm sayfalarını saha verisiyle gruplar.

Buradaki asıl değer, tek tek sayfa ölçmek yerine benzer sayfaları bir arada göstermesi. "Ürün sayfalarının tamamında LCP kötü" gibi bir çıktı, tek sayfa ölçümünün veremeyeceği bir bilgidir; düzeltmeniz gereken şablonu doğrudan işaret eder. Tek sayfayı düzeltmek bir sayfayı kurtarır, şablonu düzeltmek yüzlercesini.

Tarayıcının kendi araçları

Chrome'da F12 ile açılan geliştirici araçlarındaki Ağ (Network) sekmesi, hangi dosyanın kaç kilobayt olduğunu ve ne kadar sürede indiğini gösterir. Listeyi boyuta göre sıralayın; en üstteki birkaç satır genellikle sorunun kendisidir. Ölçüm sırasında önbelleği devre dışı bırakın, yoksa ilk kez gelen ziyaretçinin gördüğü tabloyu göremezsiniz.

Ölçümü tekrarlanabilir hale getirmek

Ölçüm sonucu her seferinde biraz oynar. Oynamayı azaltmanın yolları var:

• Tarayıcı eklentileri lab ölçümüne karışır. Gizli sekmede ya da eklentisiz bir profilde ölçün. PageSpeed Insights kullanıyorsanız bu sorun yok, ölçüm Google'ın tarafında yapılıyor.
• Aynı sayfayı üç kez ölçüp ortadaki değeri alın. Tek ölçüm gürültüdür.
• Ölçüm saatini not edin. Paylaşımlı barındırmada yoğun saatlerle gece yarısı arasında fark çıkabilir.
• Düzeltmeden önceki halin ekran görüntüsünü saklayın. Öncesi kaydedilmemişse sonrasının anlatacağı bir şey kalmıyor.
• Her turda tek bir değişiklik yapın. Aynı anda beş şeyi değiştirirseniz hangisinin işe yaradığını bilemezsiniz; birinin diğerini bozduğunu da fark edemezsiniz.

Yavaşlığın gerçek sebepleri

Sıralama, uygulamada en sık karşılaştığımız sebeplere göre.

1. Optimize edilmemiş görseller

Açık ara birinci sebep. Telefondan çekilmiş bir fotoğraf birkaç megabayt olabiliyor ve siteye olduğu gibi yükleniyor. Tarayıcı onu ekranda 400 piksel genişliğinde gösterse bile dosyanın tamamını indiriyor.

Yapılacaklar:

• Görselleri kullanılacak boyuta göre küçültün. Ekranda 800 piksel görünecek bir görselin 4000 piksel olmasının faydası yok; yüksek çözünürlüklü ekranlar için iki katı yeterli.
• WebP veya AVIF biçimine geçin. Aynı görselin JPEG'e göre belirgin şekilde küçük halini verir; kazanç görselin içeriğine göre değişir, kendi dosyanızda ölçün.
• Görselleri tembel yükleyin (lazy loading). Sayfanın altındaki görseller ziyaretçi oraya kaydırana kadar inmesin. Ekranın ilk görünen kısmındaki görsele bunu uygulamayın; orada tembel yükleme LCP'yi geciktirir.
• Her görsele genişlik ve yükseklik verin. CLS'yi düzelten şey budur.
• Dekoratif arka plan görsellerini gözden geçirin. Hiçbir bilgi taşımayan büyük bir arka plan, taşıdığı bayt kadar zarar verir.

2. Gereksiz eklenti ve script

Hazır altyapılarda en sık görülen tablo: kurulmuş yirmi eklenti, gerçekten kullanılan beşi. Kalanı her sayfada kendi CSS ve JavaScript dosyasını yüklüyor; üstelik yalnızca iletişim sayfasında gereken bir eklenti çoğu zaman tüm sayfalara kod basıyor.

Slider eklentileri, sayfa kurucular (page builder) ve "her şeyi yapan" araç paketleri bu listenin başında gelir. Bir sayfa kurucunun tek bir başlık bloğu için yüklediği kod, o başlığın kendisiyle kıyaslanmayacak kadar büyük olabiliyor.

Yapılacak iş basit: eklenti listesini açıp tek tek "bu ne işe yarıyor" diye sorun. Cevabını bilmediğiniz eklentiyi devre dışı bırakın, site bozulmuyorsa kaldırın. Önce yedek alın, sonra teker teker ilerleyin — toplu kapatmada neyin neyi bozduğu anlaşılmıyor.

3. Yazı tipi yüklemesi

Web fontları ikincil bir mesele gibi durur ama LCP'yi doğrudan etkiler. Tarayıcı yazı tipi dosyasını indirene kadar metni ya hiç göstermez ya da sonradan değiştirir.

• Kullandığınız ağırlık sayısını sayın. Çoğu site iki ağırlıkla (normal ve kalın) idare eder. Altı ağırlık yüklüyorsanız büyük kısmı boşuna iniyor olabilir.
• font-display: swap kullanın ki metin, yazı tipi gelene kadar sistem fontuyla görünsün.
• Mümkünse yazı tipini kendi alan adınızdan servis edin. Üçüncü bir alan adına kurulan her bağlantı, ayrı bir DNS çözümü ve TLS el sıkışması demek.
• İtalik gibi kullanmadığınız stilleri ve sitenizde geçmeyen alfabelerin karakter aralıklarını yüklemeyin.

4. Barındırma ve sunucu yanıt süresi

Konuşulması en az sevilen kalem. Paylaşımlı barındırmada aynı fiziksel sunucuda çok sayıda site durur. Komşu site yük aldığında sizinki yavaşlar ve bunu ölçümde sunucu yanıt süresi (TTFB) olarak görürsünüz.

Sunucu ilk baytı geç gönderiyorsa görsel sıkıştırmanın kazandıracağı şey sınırlı kalır. TTFB'yi tek başına görmek için sayfayı Ağ sekmesinde açın, ilk belgenin bekleme süresine bakın. Sürekli yüksek çıkıyorsa önce barındırmayı konuşun, sonra optimizasyonu.

Bir ayrım daha: yavaşlık her sayfada mı, yoksa yalnızca arama, sepet, filtreleme gibi sorgu çalıştıran sayfalarda mı? İkincisi genellikle barındırmanın değil, veritabanı sorgusunun ya da tek bir eklentinin sorunudur ve çözümü de farklıdır.

5. Üçüncü taraf takip kodları

Analytics, reklam pikselleri, canlı destek, çerez yönetimi, ısı haritası, sosyal medya gömüleri. Her biri tek başına makul görünür, hepsi birlikte sayfanın en ağır kısmı olabilir.

Özellikle canlı destek ve sohbet kutuları dikkat ister; büyük JavaScript paketleri getirirler ve INP'yi doğrudan bozarlar. Ölçün: kutu kapalıyken ve açıkken sonuçlar arasındaki farka bakın. O fark, kutunun size maliyetidir. Üzerinden gerçekten iş geliyorsa kalsın; aylardır kimse yazmıyorsa kaldırın.

Gömülü videolar da aynı kategoride. Sayfada bir video gömüsü varsa, video oynatılmasa bile ilgili kod iniyor. Çözüm videoyu silmek değil: kapak görseli koyup videoyu ancak tıklandığında yüklemek.

Hangi düzeltme ne kadar emek istiyor

Kesin bir kazanç oranı veremeyiz, çünkü sonuç tamamen sitenin mevcut durumuna bağlı. Ama emek ile getiri arasındaki denge şöyle sıralanıyor:

| Düzeltme | Etkilediği metrik | Emek | Getiri | |---|---|---|---| | Büyük görselleri küçültüp WebP'ye çevirmek | LCP | Düşük | Yüksek | | Görsellere genişlik/yükseklik vermek | CLS | Düşük | Yüksek | | Kullanılmayan eklentileri kaldırmak | INP, LCP | Düşük | Orta-yüksek | | Yazı tipi ağırlıklarını azaltmak | LCP | Düşük | Orta | | Karşılığı alınmayan takip kodlarını temizlemek | INP | Düşük | Orta | | Önbellekleme ve CDN kurmak | LCP, TTFB | Orta | Orta-yüksek | | Barındırmayı değiştirmek | TTFB, hepsi | Yüksek | Duruma göre çok yüksek | | Tema veya altyapıyı değiştirmek | Hepsi | Çok yüksek | Yüksek, ama son çare |

Buradaki asıl mesaj: ilk beş satır neredeyse teknik bilgi gerektirmiyor ve toplam kazancın büyük kısmını veriyor. Altyapı değiştirmeye kalkmadan önce bunları bitirin.

Puan uğruna silinmemesi gerekenler

Ölçüm aracı bazı kalemleri sorun olarak işaretler; hepsi kaldırılacak şeyler değildir.

• Çerez bandı. Ziyaretçiyi bilgilendirme ve gereken hallerde onay alma, bir tasarım tercihi değil, mevzuattan doğan bir yükümlülük olabiliyor. Bandın CLS'ye verdiği zararı bandı silerek değil, sayfada ona baştan yer ayırarak çözün. Buradaki cümleler hukuki görüş değildir; kişisel veri ve çerez yükümlülükleriniz için bağlı olduğunuz odaya ya da bir avukata danışın.
• Erişilebilirlik öğeleri. Klavye odak halkası, form etiketleri, yeterli renk kontrastı. Bunlar performans puanını zaten düşürmez, ama "sadeleştirme" turlarında elenme eğilimindedir.
• Yapısal veri ve meta etiketler. Birkaç kilobayt yer kaplarlar, aramada karşılığı olur.
• Gerçekten iş getiren araçlar. Analytics'i kapatmak puanı yükseltir, sizi kör bırakır.

Ölçüm yaparken sık yapılan hatalar

• Tek sayfa ölçüp site hakkında karar vermek. Anasayfa hızlı, ürün sayfası ağır olabilir. En az üç sayfa tipini ölçün: anasayfa, bir liste sayfası, bir detay sayfası.
• Masaüstü puanına bakmak. Mobil sonuç neredeyse her zaman daha düşüktür ve asıl önemli olan odur.
• Yerel ortamda ölçmek. Kendi bilgisayarınızda çalışan sürüm, araya ağ girmediği için gerçekçi sonuç vermez. Canlı adresi ölçün.
• Puanı kovalamak. Puan bir özettir; asıl bilgi onun altındaki listede durur.

100/100 hedef değil

PageSpeed puanını 100'e çıkarmak çoğu zaman bir tuzak. Sebebi basit: son birkaç puanı almak için genellikle sitenin işine yarayan şeylerden vazgeçmeniz gerekir. Analytics'i kaldırırsınız, canlı desteği kapatırsınız, ürün videosunu silersiniz. Puan yükselir, site kötüleşir.

Gerçekçi hedef şudur: üç Core Web Vitals ölçüsünün de "iyi" aralıkta olması. 88 puanlı ama LCP'si 1,9 saniye olan bir sayfa, 97 puanlı ama gerçek ziyaretçide üç saniyede açılan bir sayfadan iyidir.

Ayrıca puan, ölçüm aracının sürümüyle birlikte değişiyor. Aracın metrik ağırlıkları güncellendiğinde sitenize hiçbir şey yapmadan puanınız oynayabiliyor. Tek bir sayıya bağlanmayın.

Kendi sitemizde ne ölçtük

Örnek somut olsun diye kendi ölçümümüzü paylaşalım. Bu site tamamen statik üretiliyor, yazı tipleri kendi alan adımızdan geliyor ve sayfa başına inen JavaScript bilinçli olarak düşük tutuldu.

Üretim derlemesi üzerinde, mobil ayarla ve simüle edilmiş yavaş bağlantıyla üç sayfa tipinde aldığımız sonuçlar: performans 93 ile 95 arası, erişilebilirlik 100, SEO 100, CLS 0 ile 0,03 arası, LCP 2,6 ile 2,9 saniye arası.

Dürüst olmak gerekirse kendimize koyduğumuz 2,0 saniyelik LCP hedefini bu ölçümde tutturamadık. Sebebini de ölçtük: bu koşulda ilk boyamanın kendisi 2 saniyenin biraz üstünde çıkıyor ve LCP hiçbir zaman ilk boyamadan küçük olamıyor. Darboğaz yazı tipinin baytları değil, ölçüm aracının simüle ettiği ağ gecikmesi. Yazı tipi ön yüklemesini kapatmayı, yalnızca başlık yazı tipini ön yüklemeyi ve bir animasyonu ayrı katmana taşımayı denedik; ilki sonucu kötüleştirdi, diğer ikisi değiştirmedi. Ön yükleme ayarını en iyi ölçümü veren haline geri aldık.

Bunu iki sebeple yazıyoruz. Birincisi, ölçüm bazen "sıkıştırılacak bir şey kalmadı" der; o noktada zorlamak yerine darboğazın nerede olduğunu anlamak gerekir. İkincisi, bu rakamlar lab verisidir; gerçek ziyaretçilerden gelen saha verisi farklı çıkabilir ve asıl bakılacak olan odur.

Bir günlük çalışma planı

1. PageSpeed Insights'ta üç farklı sayfa tipini mobil olarak ölçün, ekran görüntülerini saklayın.
2. Search Console'da Core Web Vitals raporunu açın, hangi sayfa grubunda sorun olduğuna bakın.
3. Ağ sekmesini boyuta göre sıralayın, en ağır birkaç dosyayı tespit edin.
4. En büyük görselleri boyutlandırıp WebP'ye çevirin ve yeniden yükleyin.
5. Görsellerde genişlik ve yükseklik eksikse tamamlayın.
6. Eklenti listesini gözden geçirin, yedek aldıktan sonra kullanılmayanları devre dışı bırakın.
7. Yazı tipi ağırlıklarını sayın, gereksizleri kaldırın.
8. Üçüncü taraf kodları listeleyin, karşılığını alamadığınızı kaldırın.
9. Baştan ölçün ve iki ölçümü yan yana koyun.

Bu listeyi bitirdikten sonra hâlâ sorun görünüyorsa mesele büyük ihtimalle barındırma ya da altyapıdır. Orası ayrı bir konuşma ve daha büyük bir karar; ölçümle desteklenmeden verilmemeli.

Yardım isterseniz

Yukarıdakilerin çoğu dışarıdan destek gerektirmiyor; yazı bilerek kendiniz uygulayabileceğiniz biçimde kuruldu. Takıldığınız bir yer olursa ya da ölçüm sonucunu yorumlayamazsanız Umy Medya olarak Düzce ve çevre illerde bu işi yapıyoruz. Mevcut sitenizi ölçüp neyin ne kadar kazandıracağını yazılı olarak çıkarabiliriz; kararı ondan sonra siz verirsiniz.

Bir not: çekimi biz yapıyoruz. Yeni çekim gerekiyorsa planlıyor, çıkan görselleri web için boyutlandırıp modern biçimlere çeviriyoruz — hız sorununun büyük kısmı zaten optimize edilmemiş görsellerden doğuyor.