PageSpeed Insights Puanı Ne Anlama Gelir? Nasıl Yükseltilir?

Bir geliştiriciden ya da ajanstan gelen raporda "mobil puanımız 54" cümlesini okuyunca çoğu site sahibi önce telaşlanır, sonra da aynı soruyu sorar: bu sayı tam olarak neyi ölçüyor, düşük olması neye mal oluyor ve hangi adımı atarsam yükselir? Bu rehber o üç soruya sırayla cevap verir. Önce PageSpeed Insights aracının ne olduğunu, puanın nasıl hesaplandığını ve neden her testte aynı çıkmadığını anlatır. Sonra metrik metrik iyileştirme yollarını, ölçüm düzenini ve öncelik sırasını işler. En sonda kendi sitenizde doldurabileceğiniz bir çalışma kağıdı bulacaksınız.

Konuya daha kısa bir girişle başlamak isterseniz sayfa hızı ve Core Web Vitals rehberi yazısı temel kavramları özetler; bu yazı onun yerine geçmez, aynı konuyu çok daha ayrıntılı ve uygulama odaklı ele alır. Yazıdaki teknik ifadeler Google ve Chrome ekibinin resmi belgelerine dayanır; örnek sayılar ve tablolardaki değerler ise baştan sona kurgudur, gerçek bir siteyi temsil etmez.

PageSpeed Insights Nedir ve Ne Ölçer?

Tek ekranda iki ayrı veri kaynağı

PageSpeed Insights, bir sayfanın yükleme ve kullanım deneyimini raporlayan ücretsiz bir Google aracıdır. Adresi yazıp "Analyze" düğmesine bastığınızda ekranda iki ayrı veri bloğu görürsünüz ve rapordaki yanlış anlamaların büyük kısmı bu iki bloğu birbirine karıştırmaktan doğar.

Birinci blok, gerçek kullanıcılardan toplanan saha verisidir. Google'ın belgesine göre bu veri Chrome Kullanıcı Deneyimi Raporu'ndan (Chrome User Experience Report, kısaca CrUX) gelir ve "önceki 28 günlük toplama dönemini" kapsar. Yani burada gördüğünüz değerler, son dört haftada sayfanızı ziyaret eden gerçek insanların cihazlarında ve bağlantılarında yaşadığı deneyimin özetidir.

İkinci blok, Lighthouse'un ürettiği laboratuvar verisidir. Lighthouse, Google'ın açık kaynaklı otomatik kalite aracıdır; sayfayı kontrollü bir ortamda, simüle edilmiş bir cihaz ve ağ koşuluyla bir kez yükler, ardından performans, erişilebilirlik ve SEO gibi başlıklarda denetimler yapar. Raporun en üstündeki büyük yuvarlak puan bu ikinci bloğun performans kategorisine aittir.

Puan neyi söyler, neyi söylemez

Büyük yuvarlak sayı, o testte sayfanın yüklenirken ne kadar hızlı ve kararlı davrandığına dair bir özettir. Bir ziyaretçinin siteyi sevip sevmeyeceğini, satın alıp almayacağını ya da Google'da hangi sırada çıkacağınızı doğrudan söylemez. Puan iyi bir pusuladır ama harita değildir: nerede sorun olabileceğini gösterir, sorunun gerçek kullanıcıyı ne kadar etkilediğini ise saha verisiyle birlikte okumak gerekir.

Raporu kimler kullanır?

Rapor üç farklı okuyucuya hitap eder. Site sahibi için genel bir sağlık göstergesidir. Pazarlamacı için, bir sayfanın reklam ya da içerik eklenince yavaşlayıp yavaşlamadığını görme aracıdır. Geliştirici için ise "Fırsatlar" ve "Tanılama" bölümlerindeki somut maddeler bir iş listesine dönüşür. Aynı rapor üç kişiye üç farklı soruyu cevaplar; bu yüzden rapor paylaşılırken hangi bloğa bakıldığını yazmak toplantıları kısaltır.

Puan Renkleri ve 0 ile 100 Ölçeği Ne Anlama Gelir?

Üç aralık

Lighthouse performans puanı 0 ile 100 arasında bir sayıdır ve resmi belgede üç renkle gruplanır: 90 ile 100 arası yeşil (iyi), 50 ile 89 arası turuncu (iyileştirme gerekli), 0 ile 49 arası kırmızı (zayıf). Bu aralıklar PageSpeed Insights belgesinde de aynı biçimde verilir.

Puanın ölçeği doğrusal değildir

Resmi puanlama belgesi, her metriğin ham değerinin HTTP Archive verisinden türetilen bir log-normal dağılıma göre 0 ile 100 arasına çevrildiğini anlatır. Belgede verilen örnek şudur: bu veri setindeki sitelerin 25. yüzdeliğine denk gelen değer 50 puana, 8. yüzdeliğine denk gelen değer 90 puana karşılık gelir. Bunun sonucu önemlidir: puanın üst bölgesinde her ek puan giderek daha pahalıdır. Belge de bunu açıkça söyler; 100 puana ulaşmak çok zordur ve beklenmez, 99'dan 100'e çıkmak için gereken metrik iyileşmesi kabaca 90'dan 94'e çıkmak için gerekenle aynıdır.

Bu bilgi iki yanlış beklentiyi düzeltir. Birincisi, 40'tan 60'a çıkmak çoğu zaman tek bir doğru müdahaleyle olur ama 95'ten 100'e çıkmak aylar sürebilir. İkincisi, puanları toplayıp ortalama alarak "sitenin genel hızı" gibi bir sayı üretmek anlamsızdır; her sayfanın içeriği, görselleri ve betikleri farklıdır.

Masaüstü için ayrı eğri

Aynı belge, masaüstü testlerinin Lighthouse 6 sürümünden beri masaüstüne özgü puanlama eğrileri kullandığını belirtir. Bu yüzden aynı ham süre mobilde ve masaüstünde farklı puana dönüşür; iki puanı doğrudan kıyaslamak yerine her birini kendi cihaz sınıfında yorumlayın.

Laboratuvar Verisi ile Saha Verisi Neden Farklı Çıkar?

Tek test ile dört haftalık gerçek hayat

Laboratuvar testi tek bir simüle cihazla, sabit bir ağ koşulunda, tek bir sefer yapılır. Saha verisi ise farklı telefonlardan, farklı bağlantılardan ve farklı sayfa gezintilerinden gelen yüzbinlerce deneyimin dağılımıdır. Google'ın belgesi de bu farkı açıkça söyler: laboratuvar verisi hata ayıklama için yararlıdır ama gerçek dünyadaki darboğazları kaçırabilir; saha verisi ise gerçek kullanıcıları yansıtır fakat daha sınırlı sayıda metriği kapsar.

Kurgu bir örnek düşünelim: bir yerel haber sitesinin laboratuvar puanı 88 görünsün, saha verisinde ise LCP değeri sınırın üzerinde çıksın. Olası nedenler arasında, ziyaretçilerin önemli bölümünün eski telefonlardan bağlanması, abonelik penceresinin yalnızca gerçek kullanıcılarda açılması ya da reklam sunucusunun test sırasında boş dönmesi sayılabilir. Laboratuvar bunların hiçbirini görmez.

Yenileme hızı da farklıdır

Laboratuvar sonucu her testte yeniden üretilir; bir düzeltmeyi yaptıktan birkaç dakika sonra sonucu görürsünüz. Saha verisi ise 28 günlük bir pencerenin hareketli özetidir. Düzeltmeyi bugün yayına aldıysanız saha değerinin tam olarak yansıması haftalar alabilir. Belge, PageSpeed Insights'ın saha verisini günlük güncellediğini, BigQuery üzerindeki CrUX veri setinin ise aylık güncellendiğini ve yalnızca site (origin) düzeyinde olduğunu da not eder.

Saha verisi yoksa ne olur?

Belirli bir sayfa için yeterli CrUX verisi yoksa PageSpeed Insights, sitenin tüm sayfalarını kapsayan origin düzeyindeki veriye düşer. Origin için de yeterli veri yoksa gerçek kullanıcı verisi hiç gösterilmez. Yeni açılmış ya da trafiği düşük sayfalarda saha bloğunun boş görünmesi bir hata değildir; veri toplanacak kadar ziyaret olmamasının doğal sonucudur. Bu durumda tek referansınız laboratuvar verisidir ve onu o sınırlılığıyla okumanız gerekir.

Mobil ve Masaüstü Sonuçları Neden Birbirinden Çok Farklıdır?

Simülasyonun varsayımları

PageSpeed Insights belgesine göre mobil test, orta sınıf bir telefon (belgede Moto G4 adı geçer) ve mobil ağ koşullarını simüle eder; masaüstü test ise kablolu bağlantıya sahip emüle bir masaüstü kullanır. Testler Kuzey Amerika, Avrupa veya Asya'daki bir Google veri merkezinden çalıştırılır. Dolayısıyla mobil testte işlemci de ağ da bilerek yavaştır; bu, sayfanın zorlu koşullarda nasıl davrandığını görmek içindir.

Bu yüzden aynı sayfa masaüstünde 96, mobilde 61 alabilir. Bunu bir hata olarak değil, iki farklı kullanım koşulunun ölçümü olarak okuyun. Ziyaretçilerinizin büyük çoğunluğu mobil cihazdan geliyorsa, öncelik doğal olarak mobil sonuca verilir. Mobil deneyimin arama tarafındaki genel çerçevesi için mobil uyumluluk ve mobil öncelikli indeksleme kontrol listesi yazısına bakabilirsiniz.

Aynı kod, farklı iş yükü

Mobil testte JavaScript çalıştırmak yavaş işlemcide daha uzun sürer. Bu nedenle toplam engelleme süresi (Total Blocking Time, TBT) ve en büyük içerikli boyama (LCP) gibi metrikler mobilde daha ağır çıkar. Masaüstünde sorun yaratmayan 400 KB'lık bir betik paketi mobilde ana iş parçacığını uzun süre meşgul edebilir. İyileştirme kararlarını verirken "masaüstünde sorun yok" cümlesini yeterli saymayın.

Hangi cihaz sınıfından başlanmalı?

Karar için analitik verinizdeki cihaz dağılımına ve Search Console'daki mobil ile masaüstü ayrımına bakın. Trafik ağırlıklı olarak mobildense mobil puanı ve mobil saha verisi hedef belirlemede ana ölçüt olur. İş sitelerinde ya da panel ağırlıklı kullanımda masaüstü payı yüksek olabilir; bu durumda iki cihazı ayrı hedeflerle takip etmek makuldür.

Performans Puanını Oluşturan Metrikler ve Ağırlıkları

Beş metrik, ağırlıklı ortalama

Lighthouse performans puanı, beş metriğin ayrı ayrı puanlarının ağırlıklı ortalamasıdır. Chrome belgelerinde Lighthouse 10 için verilen ağırlıklar şöyledir; belge, yalnızca bu metriklerin puana girdiğini, "Fırsatlar" ve "Tanılama" maddelerinin doğrudan puan hesabına katılmadığını da vurgular.

Ağırlıklar Lighthouse sürümleriyle değişebilir. Bu tablo, belgenin Lighthouse 10 için yayımladığı dağılımdır; güncel sürümde bir fark olup olmadığını Lighthouse puan hesaplayıcısında hedef metrik değerlerini girerek kendiniz görebilirsiniz. Hesaplayıcı, belirli bir performans puanına ulaşmak için her metrikte hangi eşiği geçmeniz gerektiğini gösterir ve hedef koyarken çok işe yarar.

Ağırlıklardan çıkan pratik sonuç

TBT, LCP ve CLS birlikte puanın yüzde 80'ini oluşturur. Yani bir sitenin puanı düşükse, sorunun büyük olasılıkla ana iş parçacığını meşgul eden betiklerde, geç gelen büyük içerikte ya da kayan düzende aranması gerekir. FCP ve Speed Index daha küçük paya sahiptir; bunları tek başına kovalamak çoğu zaman düşük getirilidir. Bu mantık bir önceliklendirme ölçütüdür, kesin bir kural değildir: puanı yükseltmek için çalıştığınız metrik, gerçek kullanıcıyı da rahatsız eden metrik olduğunda emek en çok karşılığını verir.

Her metriği sade dille tanımlamak

İlk içerikli boyama sayfa yüklenmeye başladıktan sonra ekrana gelen ilk metin veya görseli, hız dizini ise görünür alanın ne kadar hızlı dolduğunu anlatır. En büyük içerikli boyama, görünür alandaki en büyük metin bloğunun veya görselin ekrana geldiği andır; bir haber sitesinde genellikle başlık görseli, bir ilan sayfasında ürün fotoğrafıdır. Toplam engelleme süresi, ilk içerikli boyamadan sonra ana iş parçacığının etkileşime yanıtı bozacak kadar meşgul kaldığı sürenin toplamıdır. web.dev belgesine göre 50 milisaniyeden uzun süren her ana iş parçacığı görevi "uzun görev" sayılır ve görevin 50 milisaniyeyi aşan kısmı engelleme süresine eklenir; Lighthouse ölçümü varsayılan olarak etkileşime hazır olma anında durdurur. Bu bir laboratuvar metriğidir. Kümülatif düzen kayması ise sayfa yüklenirken öğelerin yerinden kaymasını tek bir sayıyla ifade eder; ne kadar küçükse okuyucu o kadar az "tıklayacakken düğme kaydı" anı yaşar.

Core Web Vitals: LCP, INP ve CLS Eşikleri

Üç metrik, üç hedef

Core Web Vitals, Google'ın belgesinde gerçek dünya kullanıcı deneyimini yükleme performansı, etkileşim ve görsel kararlılık açısından ölçen metrikler kümesi olarak tanımlanır. Üç metrik vardır ve hedefleri şöyledir:

INP (Interaction to Next Paint), tıklama, dokunma ve klavye tuşuna basma gibi etkileşimlerden sonra sayfanın ekranı ne kadar hızlı güncellediğini ölçer. web.dev belgesine göre 200 milisaniyeye kadar iyi, 200 ile 500 milisaniye arası iyileştirme gerekli, 500 milisaniyenin üzeri zayıf sayılır. Fareyle üzerine gelme, yakınlaştırma ve kaydırma gözlenen etkileşimler arasında değildir.

75. yüzdelik ne demektir?

Hedefler, sayfa yüklemelerinin 75. yüzdeliğinde değerlendirilir ve mobil ile masaüstü ayrı ayrı bakılır. Basitçe söylemek gerekirse: sayfa ziyaretlerinin dörtte üçünün bu hedefi sağlaması istenir. Ortalama değil yüzdelik kullanılmasının nedeni, ortalamanın en yavaş deneyimleri gizleyebilmesidir. PageSpeed Insights belgesi de 75. yüzdeliğin, en sinir bozucu deneyimleri görmek ve sayfanın zor cihaz ve ağ koşullarında da çalıştığından emin olmak için seçildiğini söyler.

Geçti ya da kaldı nasıl belirlenir?

PageSpeed Insights belgesine göre yeterli veri varsa üç metriğin 75. yüzdelik değerinin üçü de "iyi" aralığındaysa Core Web Vitals değerlendirmesi geçer. INP için yeterli veri yoksa LCP ve CLS'in ikisinin iyi olması yeterlidir. LCP ya da CLS için yeterli veri yoksa değerlendirme yapılamaz. Bu değerlendirme laboratuvar puanından bağımsızdır: sayfanın laboratuvar puanı 95 olup saha değerlendirmesi başarısız çıkabilir ya da tersi olabilir.

FID'den INP'ye Geçiş: Neden Değişti?

Eski metrik ne ölçüyordu?

İlk giriş gecikmesi (First Input Delay, FID), kullanıcının sayfayla ilk etkileşiminde tarayıcının cevap vermeye başlamasındaki gecikmeyi ölçerdi. Yalnızca ilk etkileşime ve yalnızca gecikme kısmına baktığı için, sayfanın ilk saniyelerinden sonraki yavaşlıkları göremezdi.

INP neyi tamamlıyor?

web.dev belgesi INP'nin 2023'te beklemede aşamasına alındığını ve 2024'te kararlı bir Core Web Vitals metriği haline geldiğini, böylece FID'nin yerini aldığını belirtir. INP, sayfa ömrü boyunca gerçekleşen etkileşimlerin gecikmesini gözlemler ve genel olarak çoğu etkileşimin altında kaldığı tek bir değer raporlar. Bir etkileşimin gecikmesi üç parçadan oluşur: girdi gecikmesi (olay işleyicilerinin başlayabilmesi için beklenen süre), işleme süresi (işleyicilerin çalışma süresi) ve sunum gecikmesi (işleyiciler bittikten sonra karenin ekrana ulaşmasına kadar geçen süre).

Raporlarınızda ne değişir?

FID'e göre hazırlanmış eski raporlarda ya da sözleşmelerde hedef cümleleri varsa bunları güncelleyin. web.dev belgesi, INP'nin laboratuvarda ölçülmesinin zor olduğunu, TBT'nin ise INP sorunlarını işaretlemeye yardımcı olabilen bir laboratuvar göstergesi olduğunu söyler; düşük TBT çoğu zaman düşük INP ile birlikte görülür ama belge TBT'nin INP'nin yerine geçmediğini de açıkça belirtir. Gerçek INP değerini saha verisinde, yani PageSpeed Insights'ın üst bloğunda ve Search Console'un Core Web Vitals raporunda görürsünüz.

Raporun Bölümleri: Fırsatlar, Tanılama ve Geçen Denetimler

Fırsatlar

Bu bölüm, belirli bir sayfa kaynağı için tahmini kazanç süresi gösteren maddeleri listeler. Örneğin "ekran dışı görselleri ertele" ya da "kullanılmayan JavaScript'i azalt" gibi maddeler burada çıkar ve her birinin yanında tahmini bir tasarruf (kilobayt ya da milisaniye) yer alır. Bu tahminler doğrudan puana eklenmez; belgenin de belirttiği gibi puan yalnızca metriklerden hesaplanır. Fırsat maddesini kapatmak puanı artırabilir ama maddenin yanındaki süre sayfa puanına eklenecek süre anlamına gelmez.

Tanılama

Tanılama bölümü, puan hesabında yer almayan ama sayfa davranışına dair bilgi veren maddeleri toplar. Ana iş parçacığı çalışması, DOM boyutu, ağ yükü, önbellek ömürleri ve kritik istek zinciri gibi başlıklar buradadır. Geliştirici açısından bu bölüm kök neden aramanın yeridir: Fırsatlar "ne yapmalı" derken Tanılama "neden böyle" sorusuna yaklaşır.

Geçen denetimler

Bu bölüm çoğu zaman kapalı gelir ve yanlışlıkla atlanır. Burada sayfanın zaten uyguladığı iyi uygulamalar yer alır. Bir şeyi değiştirdikten sonra madde bu listeye taşınıyorsa, düzeltmenin Lighthouse tarafından algılandığını görürsünüz. Ayrıca "bu sorun sayfamda yok" sorusunun cevabını da buradan doğrularsınız.

Raporu paylaşırken neyi kaydetmeli?

Rapor bağlantısı, test tarihi, cihaz türü (mobil ya da masaüstü), laboratuvar puanı, saha verisi durumu ve hangi maddelerin açık olduğu en azından kayda geçmelidir. Bu beş bilgi olmadan iki rapor birbiriyle karşılaştırılamaz; çünkü aynı sayfa farklı zamanlarda farklı reklam, farklı konum ve farklı sunucu yükü altında test edilmiş olabilir.

LCP İyileştirme Rehberi: Ana İçeriği Daha Erken Göstermek

LCP dört parçaya ayrılır

web.dev'in LCP optimizasyon belgesi, LCP süresini birbiriyle örtüşmeyen dört alt parçaya böler: ilk bayta kadar geçen süre (Time to First Byte, TTFB; tarayıcının HTML'in ilk baytını alması), kaynak yükleme gecikmesi (TTFB ile tarayıcının LCP kaynağını yüklemeye başlaması arasındaki süre), kaynak yükleme süresi (LCP kaynağının inmesi) ve öğe oluşturma gecikmesi (kaynak indikten sonra öğenin tam olarak ekrana çizilmesi). Belge ideal dağılım için kılavuz niteliğinde bir oran verir: TTFB yaklaşık yüzde 40, kaynak yükleme gecikmesi yüzde 10'un altı, kaynak yükleme süresi yaklaşık yüzde 40, öğe oluşturma gecikmesi yüzde 10'un altı. İki gecikme parçasının sıfıra yakın olması hedeflenir.

Bu bölünme teşhisi kolaylaştırır. "LCP yavaş" demek yerine hangi parçanın şişkin olduğunu bulursunuz. Ayrıntılı anlatım için web.dev LCP optimizasyon rehberini (yeni sekmede açılır) okuyabilirsiniz.

Parça parça müdahale

Öncelik ipucu, ön yükleme ve tembel yüklemeyi yanlış yapmak

Belgenin üç net uyarısı vardır. Birincisi: LCP olması muhtemel görsel için fetchpriority=high niteliği kullanılabilir, ancak yüksek öncelik birden fazla görsele verildiğinde etkisini yitirir; belge bir ya da ikiden fazlasını önermez. Ekran dışında kalan, örneğin gizli kayan bant görselleri için ise fetchpriority=low düşünülebilir. İkincisi: LCP görseli yalnızca harici bir CSS ya da betik dosyasından çağrılıyorsa, HTML içinde yüksek öncelikli bir ön yükleme (preload) ile erken başlatılır; LCP kaynağı HTML kaynağından keşfedilebilir olmalıdır. Üçüncüsü ve en sık yapılan hata: belgenin ifadesiyle LCP görselini asla tembel yüklememelisiniz, çünkü bu her zaman gereksiz bir kaynak yükleme gecikmesi yaratır.

Pratikte bu hata genellikle şöyle doğar: bir eklenti ya da şablon, sayfadaki bütün görsellere loading=lazy niteliğini toplu olarak ekler ve ilk ekrandaki kahraman görseli de kapsar. Çözüm, ilk ekrandaki görsele bu niteliği vermemek ve yalnızca ekran dışındaki görsellerde kullanmaktır.

Sunucu yanıt süresi ve TTFB

TTFB, LCP'nin doğrudan bileşenidir; sunucu yavaşsa görsel ne kadar iyi olursa olsun LCP geç kalır. PageSpeed Insights belgesi TTFB için 800 milisaniye ve altını deneysel bir "iyi" eşiği olarak listeler. Sunucu yanıtını hızlandırmanın yollarını ağ ve sunucu bölümünde ayrıca ele alacağız.

TBT ve INP İyileştirme Rehberi: Ana İş Parçacığını Rahatlatmak

Uzun görevleri bulmak

TBT ve INP'nin ortak düşmanı uzun görevlerdir. Bir görev ana iş parçacığında 50 milisaniyeden uzun sürerse tarayıcı bu sürede kullanıcıya cevap veremez. web.dev, TBT'yi doğrudan hedeflemek yerine INP için optimize etmeyi önerir ve TBT'yi düşürmek için betik çalışmasını daha az engelleyici hale getirmeyi ya da toplam miktarını azaltmayı sayar. Lighthouse raporunun Tanılama bölümündeki "ana iş parçacığı çalışmasını en aza indirin" ve "JavaScript yürütme süresini azaltın" maddeleri hangi betiğin ne kadar süre harcadığını gösterir; ilk bakılacak yer burasıdır.

JavaScript miktarını ve bölünmesini düşünmek

Sayfanın ilk açılışta gerçekten ihtiyaç duymadığı betikleri ertelemek ya da ayrı paketlere bölüp yalnızca gerektiğinde yüklemek en etkili yollardan biridir. Sorulacak sorular basittir: bu betik ilk ekranda çalışmak zorunda mı, kullanıcı etkileşime geçmeden önce neden yükleniyor, kullanılan işlevlerin ne kadarı gerçekten çalışıyor? Kullanılmayan kod raporda "kullanılmayan JavaScript'i azaltın" maddesi olarak görünür, ama silme kararı yalnızca sayfanın bütün durumlarında denenmiş testlerden sonra verilmelidir; bir menü ya da sepet akışında yalnızca tıklayınca çalışan kod, "kullanılmıyor" görünebilir. JavaScript ağırlıklı sitelerde taramanın ve oluşturmanın nasıl etkilendiğini JavaScript SEO, render ve indeksleme yazısında bulabilirsiniz.

Olay işleyicilerini hafifletmek

INP'yi belirleyen parçalardan biri işleme süresidir, yani olay işleyicilerinin çalışma süresi. Bir düğmeye tıklandığında hem ekranı güncelleyen hem de ağır hesap yapan tek bir işleyici varsa, ekran güncellemesi hesap bitene kadar bekler. Çözüm yönü, ekranı etkileyen işi önce yapıp ağır işi sonraya bırakmaktır. Bu bir geliştirici işidir; pazarlamacı olarak geliştiricinizden talep edeceğiniz şey, "en yavaş üç etkileşimin işleme süresini ayrı ayrı çıkarın" cümlesidir.

Girdi gecikmesi ise sayfa yüklenirken ana iş parçacığı doluysa artar. Bu nedenle etkileşim ölçümü yaparken sayfa yüklenirken ve sonrasında yaygın kullanıcı akışlarını izlemek gerekir; web.dev de laboratuvar testinde bu yolu önerir, çünkü ana iş parçacığı çoğunlukla bu sırada en meşguldür.

Üçüncü taraf betikleri sorgulamak

Sohbet pencereleri, analitik etiketleri, A/B test araçları, harita ve video yerleştirmeleri ana iş parçacığında kendi görevlerini çalıştırır. Her birinin işe yaradığı bir yer vardır, ama hepsi birlikte yüklendiğinde toplam maliyet çok artabilir. Üçüncü taraf betikleri için basit bir envanter çıkarın: ad, amaç, yükleme zamanı, sahibi ve kaldırılırsa kaybedilecek şey. Sahibi olmayan ve amacı belirsiz betik kaldırma adayıdır.

CLS İyileştirme Rehberi: Kaymayan Bir Sayfa

Boyut belirtilmemiş görseller ve çerçeveler

CLS'in en sık nedeni, boyutu belirtilmemiş görseller, iframe'ler ve video oynatıcılardır. Tarayıcı dosya inene kadar ne kadar yer ayıracağını bilmez; dosya gelince altındaki bütün içerik aşağı itilir. Çözüm her görsel için genişlik ve yükseklik niteliklerini gerçek oranla vermek ya da CSS ile en-boy oranı tanımlamaktır. Böylece tarayıcı yer ayırmayı daha dosya inmeden yapar.

Font yüklemesi ve font-display

Web fontu geç geldiğinde metin ya görünmez kalır ya da yedek fontla görünüp sonra değişir; ikinci durumda yedek font ve asıl font arasındaki ölçü farkı satırları yeniden dizer ve düzen kayar. font-display ayarı bu davranışı denetler. Yedek fontun ölçülerini asıl fonta yaklaştırmak ve gerçekten kullanılan ağırlık sayısını azaltmak kaymayı düşürür. Bu konuyu fontlar bölümünde ayrıca işleyeceğiz.

Sonradan eklenen içerik

Çerez bildirimi çubukları, abonelik pencereleri, "ilgili yazılar" kutuları ve sayfa yüklendikten sonra gelen duyuru bantları içeriği aşağı iterse CLS yaratır. Kural basittir: kullanıcı bir etkileşimle istemediği sürece, görünür içeriğin üstüne yeni öğe eklemeyin. Bildirim çubukları sayfanın akışı içine değil, üstte sabit bir katman olarak ya da önceden ayrılmış bir alanda gösterilir.

Reklam ve yerleştirme alanlarına yer ayırmak

Reklam kutuları, boyutları sonradan belli olduğu için CLS'in en sinsi kaynaklarındandır. Reklam alanı için önceden bir yükseklik ayırın ve alan dolmazsa boş kalmasına izin verin ya da alan boyutunu en olası reklam ölçüsüne göre sabitleyin. Bu konuyu yayıncı ve reklam dengesi açısından ayrıca ele alacağız.

Ağ ve Sunucu Tarafı: Sıkıştırma, Önbellek, Protokol ve CDN

Sıkıştırma ve boyut

Metin tabanlı dosyalar (HTML, CSS, JavaScript, JSON) sunucu tarafında sıkıştırılarak gönderilmelidir. Bu, aktarılan bayt miktarını düşürür ve özellikle mobil bağlantılarda yükleme süresini kısaltır. Raporun Fırsatlar bölümünde "metin sıkıştırmayı etkinleştirin" benzeri bir madde görürseniz, bu genellikle sunucu yapılandırmasında tek seferlik bir ayardır. Sıkıştırma yöntemini sunucu yöneticinize ya da hosting sağlayıcınıza sorun; hangi yöntemin desteklendiği ortama göre değişir.

Önbellek başlıkları

Değişmeyen statik dosyalar (görseller, yazı tipleri, sürümlü CSS ve JS) tarayıcı önbelleğinde uzun süre tutulabilir. Dosya adına içerik özeti ya da sürüm eklemek, dosya değiştiğinde yeni adla indirilmesini sağlar ve uzun önbellek süresini güvenli kılar. Kişisel verinin bulunduğu sayfalar ve oturum bilgisi içeren yanıtlar ise herkese açık önbelleğe konmamalıdır. Önbellek kararını verirken "bu yanıt herkese aynı mı?" sorusunu sorun.

HTTP/2, HTTP/3 ve CDN

Modern protokoller aynı bağlantı üzerinden birçok kaynağın paralel iletilmesini kolaylaştırır; içerik dağıtım ağı (CDN) ise statik dosyaları kullanıcıya daha yakın sunuculardan verir. İkisi de ağ gecikmesini azaltabilir, ama hangisinin sitenizde fark yaratacağı ölçümle anlaşılır. Sunucunuz zaten yakındaki kitleye hizmet veriyorsa CDN'in kazancı sınırlı kalabilir; kitleniz farklı ülkelere dağılmışsa kazanç artar.

TTFB düşürme yolları

TTFB'yi etkileyen şeyler arasında sunucu işlemci gücü, veritabanı sorguları, sayfanın her istekte baştan üretilmesi ve yönlendirme zincirleri vardır. Tekrarlanan sorguları önbelleğe almak, sık değişmeyen sayfaların hazır HTML olarak sunulması ve gereksiz yönlendirmelerin kaldırılması yaygın adımlardır. Sunucu yanıtını yavaşlatan sayfalar aynı zamanda tarama verimliliğini de etkileyebilir; bu bağlantıyı tarama bütçesi ve crawl budget optimizasyonu yazısında ele aldık.

Görseller: Biçim, Boyut ve Yükleme Kuralları

Doğru biçim ve doğru boyut

Görseller çoğu sayfada toplam bayt miktarının en büyük payını oluşturur. Modern biçimler (WebP ve AVIF) aynı görsel kalitesinde genellikle daha küçük dosya üretir. Fakat biçim kadar boyut da önemlidir: 2400 piksel genişliğinde bir fotoğrafı 360 piksellik alanda göstermek, indirilen baytların büyük kısmını boşa harcamaktır. Kurgu bir örnek: kart görseli 400 piksel genişliğinde gösteriliyorsa, 1600 piksellik kaynak dosya yüklemek dört kat gereksiz yük yaratabilir.

Responsive görsel kümeleri

srcset ve sizes nitelikleri, tarayıcının ekran genişliğine göre uygun dosyayı seçmesini sağlar. Mobil cihaza masaüstü boyutunda görsel göndermemek hem LCP'yi hem toplam aktarım miktarını iyileştirir. Görsel arama ve görsel optimizasyonunun genel çerçevesi için görsel SEO ve Google Görseller optimizasyonu yazısı ayrıntı verir.

Tembel yükleme kuralları

Ekran dışındaki görseller için loading=lazy niteliği kullanılır; ilk ekranda görünen ve LCP adayı olan görsel ise hemen yüklenmelidir. Her görselin genişlik ve yüksekliği tanımlanmalıdır, aksi halde tembel yükleme CLS yaratır. Bir kural özeti:

• İlk ekrandaki ana görsel: tembel yükleme yok, gerekirse yüksek öncelik ipucu.
• Ekran dışı görseller: tembel yükleme açık, boyutları tanımlı.
• Kayan bandın görünmeyen slaytları: tembel yükleme, düşük öncelik.
• Dekoratif görseller: boş alt metin, bilgi taşıyan görseller: açıklayıcı alt metin.

Görsel alt metni ve içerik görseli lisansı konusunda makale görseli alt metni ve stok görsel lisansı yazısına bakabilirsiniz.

CSS ve Render Engelleyici Kaynaklar

Neden CSS sayfayı bekletir?

Tarayıcı, sayfayı çizmeden önce CSS dosyalarını indirip işlemek zorundadır; bu yüzden stil dosyaları render engelleyici kaynaktır. Raporda "boyamayı engelleyen kaynakları ortadan kaldırın" maddesi çıkıyorsa, ilk ekranın çizilmesini geciktiren CSS ve senkron betikler var demektir. Büyük ve tek parça bir stil dosyası, ilk ekranın ihtiyacı olmayan binlerce satır kural da taşıyabilir.

Küçültme, bölme ve erteleme

Üç adım sırayla düşünülür. Önce stil dosyalarını küçültün (boşluk ve yorumları temizleme). Sonra yalnızca belirli sayfa türlerinde gereken kuralları o sayfalara özel dosyalara ayırın. Son olarak ilk ekran için gereken kuralları öne çekip geri kalanı sonradan yükleme yoluna bakın. Her adım dikkatli test ister: ertelenen bir stil dosyası, sayfa ilk çizildiğinde stilsiz bir görünümün parlamasına ve CLS'e yol açabilir.

Betiklerde async ve defer

Senkron betikler HTML ayrıştırmasını durdurur. async ve defer nitelikleri betiğin ayrıştırmayı engellemeden indirilmesini sağlar; fark, çalışma zamanındadır: defer betik sırasını korur ve ayrıştırma bittikten sonra çalışır, async ise iner inmez çalışır. Bir betik başka bir betiğe bağımlıysa, sırayı bozmadan hepsine körü körüne async eklemeyin. Bu tür değişiklikleri sayfayı hem tarayıcıda hem yeniden test ederek yapın.

Fontlar: Hızlı ve Kaymasız Yazı Tipi Yükleme

Kaç font, kaç ağırlık?

Her ek font ağırlığı ayrı bir dosya demektir. Sayfada gerçekten kullanılan ağırlık ve stil sayısını sayın; kullanılmayan bir kalın italik varyantı yüklemek boşa bayt harcar. Mümkünse yalnızca gereken karakter kümesini (örneğin Latin ve Türkçe karakterleri) yükleyin.

font-display ve yedek font

font-display ayarı, font gelene kadar tarayıcının ne yapacağını belirler. Metnin okunabilir kalması genellikle önceliktir; bu yüzden font gelene kadar yedek fontla göstermeyi seçen değerler yaygın tercihtir. Yedek fontun satır yüksekliği ve harf genişliği asıl fonta yakınsa, değişim anında oluşan kayma da küçülür. Yerel olarak barındırılan fontlar, üçüncü taraf font sunucusuna ek bağlantı kurma maliyetini de ortadan kaldırır; ama bu bir tercih ve lisans meselesidir, genel bir zorunluluk değildir.

Ön yükleme, ama ölçülü

İlk ekrandaki ana başlığın fontunu önceden yüklemek metnin görünme anını öne çekebilir. Fakat her fontu ön yüklemek, daha önemli kaynakların yerini alıp LCP'yi geciktirebilir. Yalnızca ilk ekranda kullanılan bir iki dosyayı ön yükleyin ve sonucu ölçerek doğrulayın.

Üçüncü Taraf Betikler ve Reklamlar

Her etiketin bir bedeli vardır

Analitik, reklam, canlı destek, harita ve sosyal medya yerleştirmeleri kendi isteklerini ve kendi betiklerini getirir. Sizin kodunuz hızlı olsa bile bu betikler ana iş parçacığını ve ağı paylaşır. Rapordaki "üçüncü taraf kodunun etkisini azaltın" maddesi hangi alan adının ne kadar süre harcadığını gösterir. Bu madde, hangi hizmetin değerini hâlâ karşıladığını sormak için iyi bir fırsattır.

Reklam alanı sahibi için denge

Reklam gösteren yayıncılar için tablo daha karmaşıktır; reklam geliri, betik yükü ve düzen kararlılığı aynı sayfada çatışır. Akua Adforce'ta reklam alanı satan yayıncılar da bu dengeyi kurmak zorundadır: alanın kapladığı yer sabit ve öngörülebilir olmalı, alan geç dolsa bile altındaki içerik zıplamamalıdır. Reklam yerleşimi ile Core Web Vitals arasındaki dengeyi ayrıntılı işleyen reklam ve Core Web Vitals dengesi yazısı bu bölümün devamı niteliğindedir.

Yükleme zamanını kontrol etmek

Kritik olmayan üçüncü taraf betikleri sayfanın ilk çizimini beklemeden değil, sonrasında yüklemek çoğu zaman güvenlidir. Ancak bazı etiketler (özellikle rıza ve ölçüm araçları) yasal ya da işlevsel nedenlerle erken çalışmak zorundadır. Her ertelemeden önce, o etiketin veri doğruluğuna ve rıza akışına etkisini ilgili ekiple birlikte değerlendirin.

Ölçüm Yöntemi: Dalgalanmayı Yönetmek

Aynı sayfayı birkaç kez test edin

Chrome belgesi puanların Lighthouse dışındaki nedenlerle de dalgalandığını açıkça yazar: A/B testleri, değişen reklamlar, internet yönlendirme değişiklikleri, farklı donanımda test, tarayıcı eklentileri ve antivirüs yazılımları bunlar arasındadır. Belge, performansı tek bir sayı olarak değil, puanların dağılımı olarak düşünmeyi önerir. Pratik karşılığı: önemli bir sayfayı arka arkaya birkaç kez test edin, sonuçları bir aralık olarak not edin ve tek bir iyi ya da kötü sonuca göre karar vermeyin.

Puana değil metriğe hedef koyun

"Mobil puan 90 olsun" hedefi muğlaktır; hangi metriğin düzeleceğini söylemez. Daha sağlam hedef şuna benzer: "ürün listesi sayfasında mobil LCP 2,5 saniyenin altına insin" ya da "kategori sayfasında CLS 0,1'in altında kalsın". Puan hesaplayıcısı bu hedefi puana çevirmeye de yardımcı olur. Hedef metriği gerçek kullanıcı verisinden de izleyin; Search Console performans raporu arama görünürlüğü tarafını, Search Console'un Core Web Vitals raporu ise sayfa gruplarının saha durumunu gösterir.

Değişiklik günlüğü tutun

Puan değiştiğinde "ne zaman, ne değişti" sorusuna cevap verebilmek için basit bir kayıt tutun: tarih, değişikliği yapan kişi, değişikliğin ne olduğu, sayfa ve cihaz, önceki ve sonraki ölçüm. Aynı gün birden fazla değişiklik yaptıysanız hangisinin etkili olduğunu ayıramazsınız; mümkünse değişiklikleri tek tek yayına alın.

Test araçlarını ayırın

PageSpeed Insights, tarayıcı geliştirici araçlarındaki Lighthouse ve komut satırı sürümü aynı motoru kullanır ama çalıştıkları donanım ve ağ koşulu farklıdır. Chrome belgesi, yerel ve oturum gerektiren sayfaları test etmek için geliştirici araçlarının kullanılmasını önerir. Raporda hangi aracın kullanıldığını yazın ve karşılaştırmaları aynı araç ile yapın.

Öncelik Tablosu: Etki ve Efora Göre Sıralama

Hangi işi önce yapmalı?

Tüm maddeleri aynı anda yapmaya çalışmak yerine, etki ve eforu birlikte düşünerek sıralayın. Aşağıdaki tablo genel bir yönlendirmedir; sitenizdeki gerçek durum raporunuzdan çıkar. Teknik bir denetimin kapsamını ve öncelik mantığını teknik SEO denetimi kontrol listesi ve önceliklendirme yazısında ayrıca bulabilirsiniz.

Tabloyu nasıl kullanmalı?

Etkisi yüksek, eforu düşük satırlar ilk dalgadır. Etkisi yüksek ama eforu da yüksek işler için geliştirici ekibiyle ayrı bir plan yapın. Etkisi düşük, eforu yüksek işleri ise başka bir şey kalmadığında ele alın. Tablodaki etki ve efor derecelendirmesi genel bir tahmindir; sitenizin yapısına göre değişir.

100 Puan Şart mı? Yaygın Hatalar

Mükemmel puanın maliyeti

Chrome belgesi, 100 puanın çok zor ulaşılan bir hedef olduğunu ve beklenmediğini, 99'dan 100'e çıkmak için gereken metrik iyileşmesinin 90'dan 94'e çıkmak için gerekenle aynı olduğunu söyler. Yani yeşil aralığa girdikten sonra her ek puan görece pahalıdır. Yeşil aralıktaki bir sayfada saha verisi de iyiyse, kalan emeği içeriğe, dönüşüm akışına ya da başka sayfalara ayırmak çoğu zaman daha verimli olur. Puanlama mantığını Lighthouse performans puanlama belgesinde (yeni sekmede açılır) ayrıntısıyla okuyabilirsiniz.

Sık yapılan hatalar

• Yalnızca ana sayfayı ölçmek; ürün, kategori, makale ve ilan sayfaları farklı sorunlar taşıyabilir.
• Laboratuvar puanını saha verisinin yerine koymak ya da tersini yapmak.
• Tek bir testin sonucunu kesin sanmak.
• Tüm görsellere tembel yükleme verip ilk ekran görselini de kapsamak.
• Betikleri ölçmeden toplu biçimde ertelemek ve işlev kaybı yaşamak.
• Puanı yükseltmek için çerez bildirimini ya da ölçüm kodunu kaldırıp yasal ve veri sorunları yaratmak.
• Raporun uyardığı her maddeyi eşit önemde saymak.

Sayıyı süslemek yerine kullanıcıyı düşünmek

Lighthouse'u kandırmaya yönelik çözümler (içeriği testte gizleyip gerçek kullanıcıda göstermek gibi) hem etik değildir hem de saha verisinde ortaya çıkar. Hedef, rapordaki sayının değil, sayfayı kullanan kişinin deneyiminin iyileşmesi olmalıdır.

PageSpeed ve SEO İlişkisi: Google Ne Söylüyor?

Belgelenmiş çerçeve

Google'ın Core Web Vitals belgesi, site sahiplerinin Arama'da başarı için iyi Core Web Vitals değerlerine ulaşmasını önerir ve bu metriklerin çekirdek sıralama sistemlerinin ödüllendirmeyi hedeflediği şeylerle örtüştüğünü söyler. Aynı belgeler, sayfa deneyiminin tek bir sinyal olmadığını, Arama'nın alakalı içeriği, sayfa deneyimi zayıf olsa bile göstermeye çalıştığını ve güçlü Core Web Vitals değerlerinin üst sırayı sağlamadığını, çünkü iyi sayfa deneyiminin yalnızca bu skorlardan ibaret olmadığını belirtir. Google ayrıca yalnızca SEO nedeniyle mükemmel bir skor peşinde koşmanın zamanınızı kullanmak için verimli bir yol olmayabileceği uyarısını yapar. Ayrıntılar için Google'ın sayfa deneyimi belgesine (yeni sekmede açılır) bakın.

Bunun anlamı

PageSpeed puanı, Google'ın kullandığı bir sıralama puanı değildir; Lighthouse performans puanının Arama'da doğrudan kullanıldığına dair bir ifade bu belgelerde yer almaz. Sayfa deneyimi kullanıcıya yarar sağlayan bir çalışma alanıdır ve arama başarısına katkı yapabilecek birçok unsurdan biridir. Bu yüzden puan iyileştirmesini "sıralama işi" olarak değil, kullanıcı deneyimi ve teknik sağlık işi olarak planlayın. Hız çalışmasından sonra sıralama ya da trafikte bir değişim görürseniz, onu mevsimsellik, içerik değişikliği ve algoritma güncellemeleri gibi etkenlerden ayırarak yorumlayın.

Örnek Şablon: PageSpeed İyileştirme Çalışma Kağıdı (Kurgu Değerler)

Aşağıdaki tablo tamamen kurgudur; gerçek bir siteyi, gerçek bir ölçümü ya da bir kazancı temsil etmez. Kendi sayfalarınız için satırları çoğaltıp değerleri kendi ölçümlerinizle değiştirin.

Çalışma kağıdını kullanırken şu sırayı izleyin:

1. Önce her sayfa türü için tek bir temsilci sayfa seçin ve mobil raporu en az üç kez çalıştırın.
2. Saha verisi varsa değerleri hedef sütununa göre karşılaştırın.
3. Her satıra tek bir olası neden ve tek bir yapılacak iş yazın.
4. Değişikliği yayına aldıktan sonra aynı sayfayı aynı cihaz sınıfında yeniden ölçüp sonucu not edin.

Çalışma kağıdının yanında tutulacak ek kayıtlar:

• Test tarihi ve kullanılan araç.
• Değişiklik günlüğü bağlantısı.
• Saha verisinin yeterli olup olmadığı bilgisi.
• Bir sonraki ölçüm tarihi.

Sıkça Sorulan Sorular

PageSpeed Insights puanı kaç olmalı?

Chrome ve Google belgelerine göre 90 ile 100 arası yeşil yani iyi, 50 ile 89 arası turuncu, 0 ile 49 arası kırmızı kabul edilir. Ancak tek bir hedef sayı yoktur. Önce saha verisindeki LCP, INP ve CLS değerlerine bakın; yeşil aralıktaki bir sayfada kalan emeği başka sayfalara ya da içeriğe ayırmak çoğu zaman daha verimlidir.

Laboratuvar puanı ile saha verisi neden uyuşmuyor?

Laboratuvar puanı tek bir simüle cihaz ve ağ koşuluyla alınan tek bir testtir. Saha verisi ise Chrome kullanıcılarından önceki 28 gün boyunca toplanan gerçek deneyimlerin 75. yüzdeliğidir. Farklı cihazlar, bağlantılar ve sonradan yüklenen içerikler iki sonucu ayırabilir. İkisi çelişmez; aynı sayfanın iki ayrı ölçümüdür.

Mobil puan neden masaüstünden düşük çıkıyor?

PageSpeed Insights mobil testte orta sınıf bir telefonu ve mobil ağ koşullarını, masaüstü testte kablolu bağlantılı bir masaüstünü simüle eder. Mobilde işlemci ve ağ bilerek daha yavaştır; JavaScript ve büyük görseller daha çok maliyet yaratır. Bu fark çoğu zaman hata değil, ölçüm koşullarının doğal sonucudur.

LCP, INP ve CLS için hedef değerler nelerdir?

Google ve web.dev belgelerine göre iyi sayılan hedefler şöyledir: LCP 2,5 saniye veya daha kısa, INP 200 milisaniye veya daha kısa, CLS 0,1 veya daha küçük. Bu değerler mobil ve masaüstü için ayrı ayrı, sayfa yüklemelerinin 75. yüzdeliğinde değerlendirilir. INP, 2024'ten itibaren FID'in yerini alan kararlı Core Web Vitals metriğidir.

PageSpeed puanını yükseltmek sıralamayı yükseltir mi?

Google'ın belgeleri, sayfa deneyiminin tek bir sinyal olmadığını ve güçlü Core Web Vitals değerlerinin üst sırayı sağlamadığını söyler. Alakalı içerik, sayfa deneyimi zayıf olsa bile gösterilmeye çalışılır. Bu yüzden puanı sıralama aracı olarak değil, kullanıcı deneyimi çalışması olarak planlayın ve sonuç vaadi kurmayın.

Puanı yükseltmek için önce hangi adımı atmalıyım?

Önce raporda hangi metriğin zayıf olduğuna bakın. LCP görseline tembel yükleme verilmişse onu kaldırmak, görsellere boyut vermek, kullanılmayan üçüncü taraf betikleri çıkarmak ve sunucu yanıtını incelemek çoğu zaman düşük eforlu başlangıçlardır. Her değişikliği tek tek yayına alıp aynı sayfayı aynı cihaz sınıfında yeniden ölçün.

Sonuç ve Sonraki Adım

PageSpeed Insights puanı, sayfanızın belirli bir testte nasıl davrandığını gösteren yararlı bir özettir; ancak asıl karar verici, gerçek kullanıcıların yaşadığı deneyimdir. Önce saha verisini ve üç Core Web Vitals metriğini okuyun, ardından laboratuvar raporundaki fırsatları etki ve efora göre sıralayın, değişiklikleri tek tek yayına alın ve her adımı kayda geçirin. Puan sizin için bir pusuladır; hedef, daha hızlı yüklenen, kaymayan ve tıklamaya hemen cevap veren sayfalardır.

Bir sonraki adım olarak yukarıdaki çalışma kağıdını en önemli beş sayfanız için doldurun ve ilk dalgayı seçin. Aynı konuya yakın başka rehberleri okumak isterseniz SEO rehberi blog merkezini inceleyebilirsiniz. Bu yazı bir hız hizmeti anlatmaz; yalnızca ölçüm ve iyileştirme sürecini anlamanız için hazırlanmış bir rehberdir.