PageSpeed Insights Skoru Nasıl Yükseltilir?

PageSpeed Insights skoru yükseltme işi, çoğu site sahibi için mobilde kırmızı bir sayı görmekle başlar ve raporun altındaki uzun uyarı listesini tek tek uygulamaya çalışmakla devam eder. Sonuç genelde şudur: yirmi maddenin on beşi yapılır, skor 42'den 51'e çıkar, harcanan iki hafta ise geri gelmez. Bunun sebebi listenin yanlış olması değil, listenin önceliksiz olmasıdır. Rapordaki maddelerin bir kısmı skoru gerçekten hareket ettirir, bir kısmı ise ölçüm hatası payı kadar bile fark yaratmaz — ve rapor bunu size söylemez.

Bu yazıda raporu madde madde çevirmek yerine üç şeyi netleştireceğim: raporun aslında iki ayrı rapor olduğunu ve hangisinin sıralamayla ilgili olduğunu, skorun neden her ölçümde değiştiğini ve bunun normal olduğunu, son olarak da hangi uyarının gerçekten kazanç sağladığını etki sırasına göre. Yıllardır gördüğüm en yaygın hata, laboratuvar skorunun peşinde koşup gerçek kullanıcı verisini hiç açmamaktır; asıl sıralamayı etkileyen veri ise tam olarak orada durur.

PageSpeed Insights Aslında İki Ayrı Rapor#

Araç tek bir sayfa gibi görünse de içinde birbirinden bağımsız iki veri kümesi vardır ve bunları karıştırmak bu konudaki bütün kafa karışıklığının kaynağıdır.

Birincisi alan verisidir (gerçek kullanıcı deneyimi). Sitenizi gerçekten ziyaret eden insanların tarayıcılarından toplanan, son 28 günü kapsayan yuvarlanan bir ölçümdür. Burada bir "skor" yoktur; LCP, CLS ve INP değerleri ve bunların iyi/iyileştirilmeli/kötü dağılımı vardır. Sıralama sinyali olarak kullanılan veri budur.

İkincisi laboratuvar verisidir (Lighthouse). Siz o düğmeye bastığınız anda, Google'ın sunucusunda, kısıtlanmış bir sanal cihazla ve yavaşlatılmış bir ağla yapılan tek seferlik bir simülasyondur. 0-100 arası renkli skoru üreten şey budur ve bu skor doğrudan bir sıralama faktörü değildir.

Bu ayrımın pratik sonucu şudur: alan verisinde üç metrik de yeşilken laboratuvar skoru 55 olabilir. Bu tabloda yapılacak iş yoktur — gerçek kullanıcılarınız sitenizi hızlı buluyor demektir. Tersi de mümkündür: laboratuvar skoru 92 iken alan verisinde INP kırmızıdır, çünkü simülasyon kullanıcının butona tıklamasını taklit etmez. Bu yüzden raporu açtığınızda ilk bakacağınız yer üstteki renkli daire değil, sayfanın en üstündeki alan verisi bloğu olmalıdır.

Alan verisi "yeterli veri yok" diyorsa, siteniz Google'ın eşiğini dolduracak kadar trafik almıyor demektir. Bu durumda laboratuvar skoruna bakmak zorundasınız ama onu bir hedef değil, bir yön göstergesi olarak kullanın.

Laboratuvar Skoru ile Alan Verisi Neden Uyuşmaz#

İki ölçüm farklı koşullarda yapıldığı için farklı sonuç vermeleri beklenen bir durumdur. Aradaki farkın kaynakları şunlardır:

Bu tablodan çıkan en önemli sonuç, laboratuvar ölçümünün her zaman kötümser olmasıdır. Yapay kısıtlama, gerçek ziyaretçilerinizin çoğundan daha zor bir koşul yaratır. Yani laboratuvar skorunuz 60 ise gerçek kullanıcı deneyiminiz büyük olasılıkla bundan iyidir; 30 ise gerçekten bir sorun var demektir.

Bir başka fark daha var: laboratuvar yalnızca test ettiğiniz tek URL'i ölçer, alan verisi ise o URL ve genelde tüm site için toplanan veriyi gösterir. Ana sayfanız hızlı ama ürün sayfalarınız ağırsa, alan verisi bunu yansıtır, laboratuvar yansıtmaz.

Skor Her Ölçümde Neden Değişiyor#

Aynı sayfayı arka arkaya üç kez test edip 48, 61, 54 almanız normaldir ve sitenizde bir sorun olduğu anlamına gelmez. Sebepleri şunlardır:

• Sunucu yükü anlıktır. Test sırasında sunucunuz başka bir işle meşgulse ilk bayt geç gelir ve bütün metrikler kayar. Bu sürenin nasıl izole edileceğini TTFB nedir nasıl düşürülür yazısında anlattık.
• Test altyapısının kendi yükü değişir. Ölçüm sizin bilgisayarınızda değil Google'ın makinelerinde yapılır ve o makinelerin anlık yoğunluğu sonuca yansır.
• Üçüncü taraf script'ler her seferinde farklı davranır. Reklam, analitik, sohbet ve font servisleri farklı sürelerde cevap verir.
• A/B testi ve reklam rotasyonu içerik değiştirir. Her ölçümde farklı bir görsel yüklenebilir.

Doğru yöntem şudur: aynı sayfayı beş kez ölçün, en yüksek ve en düşüğü atın, ortadaki üçün ortalamasını alın. Ve asıl önemlisi, karşılaştırmayı her zaman kendi geçmiş ölçümünüzle yapın; başka bir siteyle değil.

Bir de yaygın panik var: "Dün 78'di, bugün 55 oldu, ne bozuldu?" Çoğu vakada hiçbir şey bozulmamıştır. Gerçek bir gerilemenin işareti, ölçümün bir seferliğine değil, birkaç gün boyunca tutarlı biçimde düşük çıkmasıdır.

Skoru Oluşturan Metrikler ve Ağırlıkları#

Laboratuvar skoru rastgele değil, ağırlıklandırılmış beş metriğin toplamıdır. Ağırlıklar Lighthouse'un sürümüyle birlikte güncellenebilir, ancak yaklaşık dağılım şöyledir:

Bu tablonun operasyonel anlamı çok nettir: skorun büyük kısmını TBT, LCP ve CLS belirler. Yani JavaScript yükü, en büyük görselin yüklenme hızı ve düzen kaymaları. Rapordaki "metin sıkıştırmayı etkinleştir" veya "verimli önbellek politikası kullan" gibi maddeler doğrudur ama skordaki payları bu üçünün yanında küçüktür.

Alan verisi tarafında ise metrikler farklıdır: LCP, CLS ve INP. TBT alan verisinde yoktur; onun gerçek dünyadaki karşılığı INP'dir, yani kullanıcının bir şeye tıkladıktan sonra tepki alma süresi. İkisi de aynı kök nedene bakar — ağır JavaScript.

Core Web Vitals eşikleri şöyledir ve bunlar sabittir: LCP 2,5 saniyenin altında iyi, 4 saniyenin üstünde kötü. CLS 0,1'in altında iyi, 0,25'in üstünde kötü. INP 200 milisaniyenin altında iyi, 500 milisaniyenin üstünde kötü. WordPress tarafındaki uygulaması için WordPress Core Web Vitals yazısına bakabilirsiniz.

Hangi Uyarı Gerçekten Önemli: Öncelik Tablosu#

Raporun "Fırsatlar" ve "Teşhis" bölümlerindeki maddeleri etki/emek oranına göre sıraladığımda ortaya çıkan tablo şudur.

Bu tabloyu okumanın yolu şu: üst üç satır, alttaki on satırın toplamından fazla kazandırır. Buna rağmen pratikte insanların ilk yaptığı şey CSS küçültmek olur, çünkü en kolay ve en zararsız görünen madde odur.

Somut bir örnek vereyim. Ana sayfasında 3,4 MB'lık bir kapak görseli olan bir sitede o tek görseli doğru boyutta ve modern formatta sunmak LCP'yi 5,8 saniyeden 1,9 saniyeye indirdi; skor 34'ten 71'e çıktı. Aynı sitede daha önce yapılmış olan CSS/JS küçültme işleminin skora katkısı 2 puandı.

Kozmetik Uyarılar: Vakit Kaybettiren Maddeler#

Bazı uyarılar teknik olarak doğrudur ama pratikte skoru neredeyse hiç hareket ettirmez. Bunları bilmek, iki haftanızı geri kazandırır.

"CSS'i küçült" ve "JavaScript'i küçült". Modern temalar ve eklentiler zaten küçültülmüş dosya gönderir; kalan kazanç birkaç kilobayttır. Sıkıştırma açıksa (bkz. Nginx gzip ve Brotli sıkıştırma) bu maddenin gerçek karşılığı yok denecek kadar azdır.

"Verimli önbellek politikası kullanın". Bu madde tekrar ziyaretleri iyileştirir, ama Lighthouse her zaman ilk ziyareti simüle eder. Yani düzeltseniz bile o testte skorunuz değişmez. Kullanıcı deneyimi için değerlidir, skor için değil.

"Statik varlıkları CDN üzerinden sunun" beklentisi. CDN, ziyaretçileriniz sunucunuza uzaksa fayda sağlar. Sunucunuz da ziyaretçileriniz de Türkiye'deyse fark küçüktür ve bazen ekstra bir DNS çözümlemesi yüzünden ilk yükleme bir miktar gecikir. Bu kararın nasıl verileceğini CDN mi daha iyi hosting mi yazısında ele aldık.

"Görsellerin doğru en boy oranında sunulması" gibi ince maddeler. Doğrudur, ama LCP görseli halledilmeden bunlarla uğraşmak sıralama hatasıdır.

Gerçek Kazanç Sağlayan Üç Müdahale#

LCP'yi düzeltmek#

LCP genellikle ilk ekranda görünen en büyük görseldir; bazen de büyük puntolu bir başlıktır. Hangisi olduğunu rapor size söyler ("LCP öğesi" satırı). Sırayla şunları yapın:

1. O görseli gösterildiği genişliğe göre yeniden boyutlandırın. 2400 piksellik bir görseli 800 piksellik alanda göstermek en yaygın hatadır.
2. Modern formata çevirin.
3. O görsele lazy load uygulamayın. İlk ekrandaki görselin geç yüklenmesi LCP'yi doğrudan kötüleştirir; WordPress lazy load yazısındaki istisna kuralı tam olarak budur.
4. Ön yükleme ipucu ekleyin:

<link rel="preload" as="image" href="/img/kapak.webp" fetchpriority="high">

5. Sunucu yanıt süresini kontrol edin; TTFB 1 saniyeyse LCP hiçbir zaman 2,5 saniyenin altına inemez.

Görsel iş akışının tamamı için WordPress görsel optimizasyonu yazısına bakın.

TBT ve INP'yi düzeltmek#

İkisinin de kök nedeni aynıdır: tarayıcının çalıştırmak zorunda kaldığı JavaScript miktarı. Yapılacaklar:

1. Sayfada gerçekten kullanılmayan eklentileri kaldırın. Slider, animasyon kütüphaneleri ve form eklentileri en pahalı gruplardır.
2. Kullanılmayan script'lerin yalnızca gerektiği sayfalarda yüklenmesini sağlayın. Bir iletişim formu eklentisinin script'i ana sayfada yüklenmemelidir.
3. Üçüncü taraf script'leri geciktirin. Sohbet widget'ı, ısı haritası ve reklam script'leri ilk boyamadan sonra yüklenirse TBT belirgin biçimde düşer.
4. Temanızın ilk ekran için gerektirdiği JavaScript'i sorgulayın. Bazı temalarda menü bile JavaScript ile çiziliyor olabilir.

CLS'yi düzeltmek#

CLS düzeltmesi ucuz ve etkilidir, çünkü genelde eksik ölçü bildiriminden kaynaklanır.

1. Her <img> etiketine width ve height verin. Tarayıcı yer ayırır ve görsel gelince kayma olmaz.
2. Reklam ve gömülü içerik alanlarına CSS ile sabit yükseklik tanımlayın.
3. Web fontlarında font-display: swap kullanın ve fontu ön yükleyin; yoksa metin bir yazı tipinden diğerine geçerken satırlar kayar.
4. Sayfa yüklendikten sonra tepeden içerik enjekte eden çerez bandı, duyuru çubuğu gibi öğeleri ya en baştan yer kaplayacak şekilde kurgulayın ya da sayfanın altına alın.

Mobil Skor Neden Masaüstünden Çok Düşük#

Mobil skorun masaüstünden 30-40 puan düşük olması normaldir ve sitenizde mobil özel bir sorun olduğu anlamına gelmez. Sebep, mobil testin kasıtlı olarak zor koşullar kullanmasıdır: orta seviye bir telefonun işlemci gücü ve kısıtlanmış bir mobil ağ. Aynı JavaScript paketi masaüstünde 0,8 saniyede çalışırken bu simülasyonda 4 saniye sürer.

Bu farkın operasyonel sonucu şudur: mobil skorunuzu yükseltmenin yolu neredeyse tamamen JavaScript azaltmaktan geçer. Görsel optimizasyonu her iki tarafta da işe yarar, ama masaüstü ile mobil arasındaki açığı kapatan tek şey işlem yükünü düşürmektir.

Mobil skoru okurken bir kontrol daha yapın: mobilde gerçekten farklı bir içerik mi sunuluyor? Bazı temalar mobilde ayrı bir menü, ayrı bir slider ve ek script yükler; yani mobil ziyaretçi masaüstünden daha fazla kod indirir. Bu, düzeltilmesi gereken gerçek bir hatadır.

100 Skor Neden Yanlış Bir Hedef#

100 puan, üzerinde reklam, analitik, sohbet, harita veya gömülü video bulunmayan sade bir sayfada mümkündür. Gerçek bir ticari sitede bunların hepsini çıkarmadan 100 almak pratik olarak imkânsızdır ve zaten gerekli de değildir.

Anlamlı hedef şudur: alan verisindeki üç metriğin de "iyi" eşiğinde olması. LCP 2,5 saniyenin altında, CLS 0,1'in altında, INP 200 milisaniyenin altında. Bu tabloyu yakalayan bir site laboratuvar skoru 75 gösterse bile gerçek kullanıcı deneyimi bakımından sağlıklıdır ve arama tarafında bir performans dezavantajı yaşamaz.

Skor peşinde koşmanın gerçek maliyeti şudur: son 10 puanı almak için sohbet widget'ını kaldırıp müşteri iletişimini, analitiği kaldırıp ölçümü, ödeme script'ini erteleyip dönüşümü feda edersiniz. Rakam yükselir, iş kötüleşir. Performans çalışmasının SEO tarafındaki yerini WordPress SEO başlangıç yazısında ele aldık; hız, içerik ve teknik yapının yerine geçmez.

Ölçüm Disiplini: Değişikliği Nasıl Doğrularsınız#

Yaptığınız işin sonucunu görebilmek için ölçümü disiplinli tutmak gerekir.

1. Başlangıç ölçümünü kaydedin. Skor, LCP, CLS, TBT değerlerini ve tarihini bir yere yazın.
2. Tek seferde tek değişiklik yapın. Aynı gün üç şey değiştirirseniz, hangisinin işe yaradığını bilemezsiniz ve biri sorun çıkarırsa geri almanız zorlaşır.
3. Değişiklikten sonra önbelleği temizleyin. Hem site önbelleğini hem varsa CDN önbelleğini. Aksi halde eski sürümü ölçersiniz.
4. Beş ölçüm alın, ortancasını kullanın. Tek ölçüme bakıp karar vermeyin.
5. Alan verisini haftalık kontrol edin. Alan verisi 28 günlük yuvarlanan bir penceredir; bugün yaptığınız iyileştirme grafiğe birkaç hafta içinde tam olarak yansır. Bu gecikmeyi bilmemek, "düzelttim ama değişmedi" yanılgısının bir numaralı sebebidir.

Sunucu tarafının bu tabloya katkısını ayırmak isterseniz, önce ilk bayt süresini izole edin; yöntem sitem neden yavaş açılıyor yazısında adım adım anlatılıyor. Bağımsız bir ikinci ölçüm noktası kullanmak da faydalıdır, ancak iki farklı aracın rakamlarını birbiriyle değil, her birini kendi geçmiş sonucuyla karşılaştırın.

Sıkça Sorulan Sorular#

PageSpeed skoru Google sıralamasını doğrudan etkiler mi#

Hayır, 0-100 arasındaki laboratuvar skoru doğrudan bir sıralama faktörü değildir. Sıralamaya giren şey, gerçek kullanıcılardan toplanan alan verisindeki Core Web Vitals metrikleridir: LCP, CLS ve INP. Bu metrikler eşik değerlerin içindeyse laboratuvar skorunuzun 70 olması bir dezavantaj yaratmaz. Bu yüzden raporu açtığınızda önce sayfanın üstündeki alan verisi bloğuna, sonra renkli daireye bakın.

Skorum her ölçümde değişiyor, bu normal mi#

Evet, tamamen normaldir ve 10-15 puanlık dalgalanma beklenen bir aralıktır. Ölçüm sırasındaki sunucu yükü, test altyapısının anlık yoğunluğu, üçüncü taraf script'lerin değişken yanıt süreleri ve reklam rotasyonu her seferinde farklı sonuç üretir. Doğru yöntem beş ölçüm alıp ortancasını kullanmak ve karşılaştırmayı yalnızca kendi geçmiş ölçümlerinizle yapmaktır. Gerçek bir gerileme, tek bir düşük sonuçla değil birkaç gün süren tutarlı bir düşüşle anlaşılır.

Mobil skorum masaüstünden çok düşük, sorun ne#

Mobil test kasıtlı olarak zor koşullar kullandığı için bu fark normaldir. Simülasyon orta seviye bir telefonun işlemcisini ve kısıtlanmış bir mobil bağlantıyı taklit eder; masaüstünde bir saniyede çalışan JavaScript burada birkaç saniye sürer. Aradaki açığı kapatmanın neredeyse tek yolu JavaScript yükünü azaltmaktır. Ayrıca temanızın mobilde ek script yükleyip yüklemediğini kontrol edin, çünkü bazı temalarda mobil ziyaretçi masaüstünden daha fazla kod indirir.

En büyük içerik öğesi görseli nasıl hızlandırılır#

Öncelikle o görseli gösterildiği genişliğe göre yeniden boyutlandırın ve modern bir formata çevirin; en yaygın hata 2000 piksellik bir görseli 800 piksellik alanda göstermektir. İkinci olarak o görsele geç yükleme uygulamayın, çünkü ilk ekrandaki görselin ertelenmesi LCP'yi doğrudan kötüleştirir. Üçüncü olarak rel="preload" ile ön yükleme ipucu verin. Son olarak sunucu yanıt süresini kontrol edin; ilk bayt bir saniyede geliyorsa LCP'nin iyi eşiğe inmesi mümkün değildir.

100 puan almak gerekli mi#

Gerekli değildir ve çoğu ticari sitede pratik olarak mümkün de değildir. Reklam, analitik, sohbet, harita ve ödeme script'leri kaçınılmaz bir maliyet yaratır; bunları kaldırarak alınan yüksek puan işin kendisine zarar verir. Anlamlı hedef, alan verisindeki üç metriğin de iyi eşikte olmasıdır. Bu sağlandığında laboratuvar skorunun 70 ile 90 arasında kalması hiçbir dezavantaj yaratmaz.

İyileştirme yaptım ama alan verisi değişmedi, neden#

Alan verisi son 28 günü kapsayan yuvarlanan bir penceredir, bu yüzden yaptığınız değişiklik grafiğe hemen yansımaz. İyileştirmeden sonraki ilk günlerde grafik hâlâ eski deneyimin ağırlıklı ortalamasını gösterir; tam etki genellikle birkaç hafta içinde görünür hâle gelir. Laboratuvar ölçümünde iyileşme görüyorsanız yaptığınız iş doğrudur, beklemeniz yeterlidir. Bu gecikmeyi bilmemek en yaygın "düzeltmem işe yaramadı" yanılgısıdır.

Hangi uyarıyla başlamalıyım#

En büyük içerik öğesi görselini optimize etmekle başlayın; tek maddede en yüksek kazanç oradan gelir. Ardından kullanılmayan JavaScript'i kaldırmaya, sonra görsellere width ve height vererek düzen kaymalarını gidermeye geçin. Bu üçü çoğu sitede kalan bütün maddelerin toplamından fazla kazandırır. CSS/JS küçültme ve önbellek politikası gibi maddeler doğrudur ama etkisi küçük olduğu için listenin sonunda kalmalıdır.

Hosting değiştirmek PageSpeed skorumu yükseltir mi#

Yalnızca sunucu yanıt süreniz yüksekse yükseltir. İlk bayt süreniz bir saniyenin üzerindeyse LCP ve FCP doğrudan etkilenir ve daha hızlı bir ortam gözle görülür fark yaratır. Ancak sunucunuz 200 milisaniyede cevap veriyorsa, skorunuzu düşüren şey indirilen görseller ve çalıştırılan JavaScript'tir; bu durumda hosting değiştirmek hiçbir şeyi değiştirmez. Karar vermeden önce mutlaka ilk bayt sürenizi ölçün.

Kapanış#

PageSpeed Insights skoru yükseltme işi, uzun bir uyarı listesini baştan sona uygulamak değil; raporu doğru okumaktır. İki ayrı veri kümesi olduğunu, sıralamayla ilgili olanın alan verisi olduğunu, skorun her ölçümde dalgalanmasının normal olduğunu ve maddelerin çok küçük bir kısmının gerçek kazanç sağladığını bilirseniz, iki haftalık işi iki güne indirirsiniz. Öncelik her zaman aynıdır: en büyük görsel, JavaScript yükü, düzen kaymaları. Gerisi ince ayardır ve bu üçü halledilmeden yapıldığında ölçülemez.

Ölçümünüz sunucu yanıt süresini işaret ediyorsa, kaynakları izole eden bir yapı kalıcı fark yaratır; VDS sunucu paketleri bu ihtiyaca göre kurgulanmıştır. Önbellek, PHP sürümü ve sunucu tarafı ayarların hazır gelmesini istiyorsanız WordPress hosting paketleri bu yapılandırmayı üstlenir; düzenli bakım ve iyileştirmeyi devretmek isterseniz WordPress bakım hizmeti bu işi sürdürür. Performans çalışmasını içerik ve teknik SEO ile birlikte yürütmek isterseniz SEO tarafındaki hizmetler bu süreci tamamlar.