Google Lighthouse ile Site Performans Testi Nasıl Yapılır? Skoru Yükseltme Rehberi

Lighthouse testi, bir sayfanın hızını, erişilebilirliğini ve temel teknik sağlığını birkaç dakikada ölçen ücretsiz bir Google aracıdır. Müşterilerimle yaptığım ilk görüşmelerin çoğunda masaya bir skor ekran görüntüsü gelir: bazen 38, bazen 92. Ancak o sayının ne anlattığını ve ne anlatmadığını bilmeden yapılan iyileştirme, çoğu zaman yanlış yere harcanan emektir. Bu rehberde testi doğru koşmayı, raporu okumayı ve en sık önerileri sırayla çözmeyi anlatıyorum.

Lighthouse testi nedir ve neyi ölçer?

Lighthouse testi, Google'ın açık kaynak aracı Lighthouse ile bir sayfayı kontrollü bir ortamda yükleyip performans, erişilebilirlik, en iyi uygulamalar ve SEO kategorilerinde 0 ile 100 arasında puan veren laboratuvar ölçümüdür. Sonuç, gerçek ziyaretçilerin deneyimini değil, sabit koşullardaki tek bir yüklemeyi yansıtır.

Performans kategorisi beş metriğe bakar: First Contentful Paint (ilk içerikli boyama), Speed Index, Largest Contentful Paint (en büyük içerikli boyama), Total Blocking Time (toplam engelleme süresi) ve Cumulative Layout Shift (kümülatif düzen kayması). Her metrik ayrı puan alır, ardından ağırlıklı ortalama genel skoru oluşturur.

Öte yandan Lighthouse yalnızca teşhis koymaz; her sorunun yanına tahmini kazanç ve ilgili dosyaları da yazar. Bu yüzden onu bir karne gibi değil, bir muayene raporu gibi okumanızı öneririm. Karne size geçtiniz mi kaldınız mı der; muayene raporu ise neyin, nerede ve ne kadar ağrıdığını gösterir.

Lighthouse ile PageSpeed Insights arasındaki fark nedir?

İkisi aynı motoru kullanır, ancak farklı yerlerde çalışır. Lighthouse, Chrome DevTools içinde, komut satırında veya bir eklenti olarak sizin bilgisayarınızda koşar. PageSpeed Insights ise aynı Lighthouse sürümünü Google'ın sunucularında çalıştırır ve üstüne gerçek kullanıcı verisini ekler.

Kısacası geliştirme sırasında DevTools, yayındaki sayfanın durumunu görmek için PageSpeed Insights daha doğru seçimdir. Ben ikisini birlikte kullanıyorum: önce PageSpeed Insights ile saha verisine bakıyor, sonra sorunu DevTools'ta yerelde yeniden üretiyorum.

Bir de şunu hatırlatayım: PageSpeed Insights mobil testi orta seviye bir telefonu ve yavaşlatılmış bir mobil bağlantıyı taklit eder, masaüstü testi ise kablolu bağlantı varsayar. Kendi bilgisayarınızdaki DevTools testi de benzer bir yavaşlatma uygular, fakat işlemci gücünüz sonucu yine etkiler. Bu yüzden iki aracın skorlarını birbirine karıştırmayın; karşılaştırmayı her zaman aynı araç ve aynı ayar içinde yapın. Aksi halde gerçekte hiçbir şey değişmemişken iyileşme ya da gerileme gördüğünüzü sanabilirsiniz.

Laboratuvar verisi ile saha verisi neden farklı sonuç verir?

Laboratuvar verisi tek bir cihaz ve tek bir bağlantı hızıyla yapılan simülasyondur. Saha verisi ise Chrome kullanıcılarından toplanan Chrome User Experience Report (CrUX) kayıtlarıdır. PageSpeed Insights belgelerine göre saha verisi son 28 günü kapsar ve 75. yüzdelik dilime göre değerlendirilir.

Dolayısıyla iki veri aynı sayfa için farklı hikâye anlatabilir. Laboratuvarda LCP 4 saniye görünürken sahada iyi çıkabilir, çünkü ziyaretçilerinizin çoğu hızlı telefon ve Wi-Fi kullanıyor olabilir. Tam tersi de mümkündür: laboratuvar temiz görünürken sahada kötü INP çıkar, çünkü laboratuvar kimsenin düğmeye bastığını görmez.

Peki hangisine güvenmelisiniz? Google'ın arama sistemleri gerçek kullanıcı deneyimine baktığı için karar verirken saha verisi önceliklidir. Laboratuvar verisi ise nedenini bulmanızı ve düzeltmeyi hemen doğrulamanızı sağlar. Saha verisinin iyileşmeyi göstermesi için 28 günlük pencerenin dolmasını beklemeniz gerekir. Bu arada düşük trafikli sayfalarda saha verisi hiç görünmeyebilir; o durumda elinizde yalnız laboratuvar ölçümü kalır.

Lighthouse testini hangi yollarla yapabilirsiniz?

Lighthouse testini dört farklı yoldan çalıştırabilirsiniz. Hangisini seçeceğiniz, kimin test ettiğine ve ne sıklıkla test ettiğinize bağlıdır:

• PageSpeed Insights: Adresi yapıştırırsınız, sonuç tarayıcıda gelir. Kurulum yoktur, pazarlama ekibi için en kolay yoldur.
• Chrome DevTools: Sayfada sağ tıklayıp İncele dersiniz, Lighthouse sekmesinden raporu alırsınız. Giriş gerektiren sayfalar ve test ortamı için idealdir.
• Komut satırı (CLI): Node.js kuruluysa "npm install -g lighthouse" ile yüklersiniz. Aynı sayfayı birkaç kez koşup ortalama almak için en pratik araçtır.
• Lighthouse CI: Her kod değişikliğinde testi otomatik çalıştırır ve skor belirlediğiniz eşiğin altına düşerse yayını durdurur.

Küçük bir kurumsal site için ilk ikisi yeterlidir. Ancak haftada birkaç kez güncellenen bir e-ticaret sitesinde CLI ya da Lighthouse CI kurmadan gerilemeleri yakalamanız zordur.

Chrome DevTools ile testi adım adım nasıl çalıştırırsınız?

DevTools yolu, en çok kontrol veren yoldur. Benim her projede izlediğim sıra şöyle:

1. Chrome'u gizli pencerede açın. Eklentiler sonucu bozar; gizli pencere çoğunu devre dışı bırakır.
2. Test edeceğiniz sayfayı açın, F12 ile DevTools'u başlatın ve Lighthouse sekmesine geçin.
3. Mod olarak "Navigation" seçin. Bu mod sayfanın ilk yüklenişini ölçer.
4. Cihaz olarak önce "Mobile" seçin, çünkü Google dizine eklemede mobil sürümü esas alır.
5. Kategorilerden yalnız Performans'ı işaretleyin; test daha hızlı biter.
6. "Analyze page load" düğmesine basın ve rapor gelene kadar sekmeyi başka işe kullanmayın.
7. Aynı testi en az üç kez tekrarlayın ve ortanca sonucu not edin.

Ayrıca raporu JSON veya HTML olarak kaydedin. İyileştirmeden sonra aynı ayarlarla yeni rapor alıp ikisini yan yana koyduğunuzda neyin değiştiğini tartışmasız görürsünüz. Timespan modu ise sayfadaki tıklamalar sırasında olanları kaydeder; etkileşim sorunlarını ararken işe yarar.

Lighthouse performans skoru nasıl hesaplanır?

Skor, beş metriğin ağırlıklı ortalamasıdır. Chrome for Developers belgesine göre güncel ağırlıklar şöyledir:

• Total Blocking Time: yüzde 30
• Largest Contentful Paint: yüzde 25
• Cumulative Layout Shift: yüzde 25
• First Contentful Paint: yüzde 10
• Speed Index: yüzde 10

Her metriğin ham değeri, HTTP Archive'daki gerçek sitelerden türetilen bir dağılım eğrisine yerleştirilir ve 0 ile 100 arasında puana çevrilir. Renk bantları da aynı belgede tanımlıdır: 0 ile 49 arası kırmızı, 50 ile 89 arası turuncu, 90 ve üzeri yeşil.

Bu tablodan çıkan pratik sonuç açık: skorun yüzde 80'i üç metrikte toplanır. Yani TBT, LCP ve CLS düzelmeden genel skoru kalıcı olarak yükseltemezsiniz. Öte yandan eğri doğrusal değildir; 50'den 70'e çıkmak kolaydır, 90'dan 100'e çıkmak ise çoğu zaman orantısız emek ister.

Skor neden her testte değişir?

Aynı sayfayı arka arkaya iki kez test ettiğinizde 71 ve 78 görmeniz normaldir. Chrome belgeleri bu dalgalanmanın başlıca nedenlerini sayar: A/B testleri, dönen reklamlar, internet yönlendirmesindeki değişiklikler, farklı cihazlar, tarayıcı eklentileri ve antivirüs yazılımları.

Sahada gördüğüm en yaygın sebepler ise şunlar: sunucunun o an yoğun olması, önbelleğin henüz ısınmamış olması, üçüncü taraf betiklerin her yüklemede farklı sürede gelmesi ve test eden bilgisayarda arka planda çalışan programlar. Bu nedenle tek bir ölçümle karar vermem.

Pratik kuralım basit: aynı koşulda en az üç, tercihen beş test koşarım ve ortanca değeri kaydederim. Değişikliğin etkisini ölçerken de önce ve sonra testlerini aynı gün, aynı ağda ve aynı cihazda yaparım. Böylece skor farkının sizin düzeltmenizden mi yoksa şanstan mı geldiğini ayırt edersiniz. Beş puanın altındaki farkları gürültü kabul etmek, saha tecrübeme dayanan bir başlangıç kuralıdır, garanti değil.

Lighthouse raporunu nasıl okumalısınız?

Raporu yukarıdan aşağıya değil, önem sırasına göre okuyun. Önce Metrics bölümüne bakın: beş metriğin hangisi kırmızı veya turuncu? Genel skordan çok bu tablo işinize yarar, çünkü sorunun türünü söyler.

Ardından Insights bölümüne geçin. Lighthouse 13 ile Google, eski ayrı denetimleri DevTools Performans panelindeki içgörülerle birleştirdi; örneğin görsel biçimi, sıkıştırma ve boyut uyarıları artık tek bir "Improve image delivery" başlığında toplanıyor. Her içgörünün yanında tahmini kazanç ve ilgili dosyalar yazar.

Diagnostics bölümü ise doğrudan puan etkisi göstermeyen ama nedeni açıklayan bilgileri içerir: ana iş parçacığı yükü, DOM boyutu, önbellek süreleri gibi. Passed audits kısmını ilk okumada atlayabilirsiniz.

Son olarak, "Show audits relevant to" filtresini kullanın. LCP'ye tıkladığınızda rapor yalnız LCP'yi etkileyen maddeleri gösterir. Bu filtre, onlarca uyarı arasında kaybolmadan en büyük kalemi bulmanın en hızlı yoludur.

LCP yavaşsa ne yapmalısınız?

LCP, sayfadaki en büyük görünür öğenin ekrana geldiği andır; iyi eşik 2,5 saniyedir. Kurumsal sitelerde bu öğe genellikle hero görseli, slider'ın ilk karesi veya büyük bir başlık metnidir. Raporda "LCP breakdown" içgörüsü süreyi dört parçaya böler: sunucu yanıtı, kaynağın yüklenmeye başlama gecikmesi, kaynağın indirilme süresi ve boyama gecikmesi.

Hangi parça büyükse çözüm oradadır. En sık gördüğüm üç durum ve çözümü:

• Görsel geç keşfediliyor: Görsel CSS arka planı veya JavaScript ile yükleniyorsa tarayıcı onu geç fark eder. Bunun yerine img etiketi kullanın ve fetchpriority="high" ekleyin.
• Görsel lazy loading ile yükleniyor: Ekranın üstündeki görsele loading="lazy" koymak LCP'yi doğrudan geciktirir. Bu özelliği yalnız aşağıdaki görsellerde kullanın.
• Görsel çok büyük: 3000 piksellik bir fotoğrafı 400 piksellik alanda göstermek boşa indirmedir. Boyutlandırıp WebP veya AVIF'e çevirin.

Görsel boyutunu hızlıca küçültmek için resim küçültme aracını kullanabilirsiniz. Ancak kalıcı çözüm, sitenin görselleri otomatik boyutlandıran bir yapıya sahip olmasıdır.

Total Blocking Time neden yüksek çıkar?

TBT, sayfa yüklenirken ana iş parçacığının 50 milisaniyeden uzun süren görevlerle meşgul kaldığı toplam süredir. Bu sürede kullanıcı tıklasa bile tarayıcı cevap veremez. Skordaki ağırlığı yüzde 30 olduğu için tek başına en etkili metriktir.

Yüksek TBT'nin neredeyse her zaman sebebi JavaScript'tir. Hazır temalar, sayfa oluşturucular, sohbet balonları, çerez bildirimleri ve birden fazla analitik etiketi aynı anda çalıştığında ana iş parçacığı tıkanır. Örneğin bir WordPress sitesinde yalnız iletişim sayfasında kullanılan form eklentisinin her sayfada yüklendiğini sık görürüm.

Çözüm sırası benim için şöyle: önce kullanılmayan betikleri kaldırırım, sonra kalanları defer veya async ile ertelerim, ardından ağır bileşenleri etkileşimde yüklerim. Raporda "Reduce JavaScript execution time" ve "Minimize main-thread work" maddeleri hangi dosyanın ne kadar süre harcadığını gösterir.

Ayrıca şunu bilmekte fayda var: Lighthouse sayfa açılışında kimse tıklamadığı için INP'yi ölçemez. TBT bu nedenle INP'nin laboratuvardaki yaklaşık göstergesi gibi çalışır. TBT'yi düşürdüğünüzde sahadaki INP de genellikle iyileşir.

CLS kaymalarını nasıl düzeltirsiniz?

CLS, sayfa yüklenirken içeriğin beklenmedik şekilde yer değiştirmesini ölçer; iyi eşik 0,1'dir. Okurken metnin aşağı kaydığını ya da tam tıklayacakken düğmenin yer değiştirdiğini hepimiz yaşadık. Bu hem kullanıcıyı sinirlendirir hem de yanlış tıklamaya yol açar.

Raporda "Layout shift culprits" içgörüsü kaymaya sebep olan öğeleri listeler. En sık nedenler ve çözümleri şunlardır:

• Genişlik ve yükseklik değeri olmayan görseller: img etiketine width ve height yazın ya da CSS'te aspect-ratio verin.
• Sonradan yüklenen reklam ve gömülü içerikler: bu alanlar için önceden sabit yükseklikte yer ayırın.
• Web fontlarının geç gelmesi: font-display ayarını ve yedek fontun ölçülerini kontrol edin.
• Üstten açılan çerez bantları ve duyuru şeritleri: bunları içeriği itmeyecek şekilde sabit konumda gösterin.

Özellikle çerez bandı konusunu atlamayın. Birçok sitede tek başına CLS'nin büyük kısmını oluşturduğunu gördüm ve çözümü çoğu zaman birkaç satır CSS'tir.

Görsel önerilerini nasıl çözersiniz?

Lighthouse 13'te görselle ilgili uyarılar "Improve image delivery" içgörüsünde toplanır. Bu içgörü üç şeye bakar: görsel modern bir biçimde mi, yeterince sıkıştırılmış mı ve gösterildiği alana uygun boyutta mı?

Dolayısıyla çözüm de üç adımdır. İlk olarak JPEG ve PNG dosyalarını WebP veya AVIF biçimine çevirin; tüm güncel tarayıcılar WebP'yi destekler. İkinci olarak kaliteyi gözle fark edilmeyecek düzeye indirin. Üçüncü olarak srcset ile farklı ekranlara farklı boyut sunun, böylece telefon masaüstü görselini indirmez.

Bu işi tek tek elle yapmak yerine sistemi kurmanızı öneririm. WordPress'te bir görsel optimizasyon eklentisi, özel yazılımda ise yükleme anında boyutlandıran bir görsel hattı bu sorunu kalıcı olarak kapatır. Ben web tasarım projelerinde görsel hattını ilk günden kuruyorum, çünkü içerik ekibi her fotoğrafı elle küçültmeyi birkaç ay sonra bırakır. Ürün görseli yoğun mağazalarda bu konu daha da kritiktir; e-ticaret danışmanlığı sırasında ilk baktığım kalemlerden biridir.

Web fontları ve önbellek ayarları skoru nasıl etkiler?

Kurumsal sitelerde marka fontu vazgeçilmezdir, ancak her yazı kalınlığı ayrı bir dosya demektir. Dört farklı ağırlık ve iki farklı aile kullanan bir tema, ilk yüklemede sekiz font dosyası indirebilir. Raporda "Font display" içgörüsü, metnin font gelene kadar görünmez kaldığı durumları işaretler.

Benim önerim şu: kullandığınız ağırlık sayısını ikiye veya üçe indirin, fontları kendi sunucunuzda WOFF2 biçiminde barındırın ve font-display ayarını swap ya da optional yapın. Böylece metin ilk anda yedek fontla görünür, marka fontu gelince yer değiştirir. Yedek fontun ölçülerini yakın seçerseniz bu geçiş CLS de üretmez.

Önbellek tarafında ise "Use efficient cache lifetimes" içgörüsü, tekrar ziyarette yeniden indirilen dosyaları gösterir. CSS, JavaScript, görsel ve font dosyalarına uzun önbellek süresi verin; dosya adına sürüm eki koyarsanız güncellemeler de sorunsuz yansır. Bu ayar Lighthouse testinin ilk yükleme skorunu pek değiştirmez, fakat sitenizde birden fazla sayfa gezen ziyaretçinin deneyimini belirgin şekilde hızlandırır.

Ayrıca sunucu tarafında Brotli veya Gzip sıkıştırmasının açık olduğundan emin olun. Metin dosyalarında bu ayarın kapalı olduğunu, özellikle eski paylaşımlı hosting paketlerinde hâlâ görüyorum.

Oluşturmayı engelleyen kaynakları ve kullanılmayan kodu nasıl temizlersiniz?

Tarayıcı, sayfanın başındaki CSS ve senkron JavaScript dosyalarını indirip işlemeden ekrana hiçbir şey çizmez. Raporda "Render blocking requests" içgörüsü bu dosyaları ve tahmini kazancı listeler.

Çözüm için şu adımları izleyin. Önce ilk ekran için gereken kritik CSS'i ayırıp satır içine alın, geri kalanı ertelenmiş yükleyin. Sonra JavaScript dosyalarına defer ekleyin; defer, betiği indirirken sayfanın çizilmesini durdurmaz. Ardından "Reduce unused JavaScript" ve "Reduce unused CSS" maddelerine bakın. Hazır temalarda CSS'in yarısından fazlasının o sayfada hiç kullanılmadığını görmek sürpriz değildir.

Ancak burada dikkatli olun. Kritik CSS'i yanlış ayırırsanız sayfa bir an stilsiz görünür; bu da kullanıcı deneyimini bozar. Bu yüzden her değişiklikten sonra sayfayı yavaş bağlantıda gözle kontrol edin. DevTools'taki Coverage sekmesi, hangi kodun gerçekten kullanıldığını satır satır gösterir ve temizlik için iyi bir başlangıç noktasıdır.

Üçüncü taraf betikler skoru nasıl etkiler?

Üçüncü taraf betikler, sizin sunucunuzdan değil başka bir alan adından gelen kodlardır: analitik etiketleri, reklam pikselleri, sohbet araçları, harita ve video gömmeleri, yorum eklentileri. Raporda "3rd parties" içgörüsü her birinin aktarım boyutunu ve ana iş parçacığında harcadığı süreyi gösterir.

Bu betikler çoğu zaman pazarlama için gereklidir, dolayısıyla hepsini silmek çözüm değildir. Bunun yerine her biri için şu soruyu sorun: bu etiket bugün hangi kararı besliyor? Yıllar önce kurulmuş ve kimsenin açmadığı ısı haritası betikleri, kullanılmayan piksel etiketleri ve iki kez yüklenen analitik kodu en sık bulduğum fazlalıklardır.

Kalanlar için yükleme zamanını erteleyin. Sohbet balonunu kullanıcı ilk etkileşimi yaptığında yükleyin, YouTube videosu yerine önce bir önizleme görseli koyun, harita yerine tıklanınca açılan statik bir görsel kullanın. Böylece pazarlama ölçümünü kaybetmeden ilk yüklemedeki yükü ciddi ölçüde azaltırsınız. Etiketleri Google Tag Manager üzerinden yönetiyorsanız tetikleyicileri de gözden geçirin.

Sunucu yanıt süresi skoru neden etkiler?

Sunucu ilk baytı geç gönderirse arkadan gelen her şey gecikir. PageSpeed Insights belgelerinde TTFB için iyi eşik 800 milisaniye olarak geçer. Lighthouse 13'te bu konu "Document request latency" içgörüsünde görünür; yönlendirmeler, sunucu süresi ve sıkıştırma aynı başlıkta değerlendirilir.

En sık nedenler şunlar: paylaşımlı hostingde kaynak yetersizliği, sayfa önbelleğinin hiç kullanılmaması, eski PHP sürümü, ağır veritabanı sorguları ve zincirleme yönlendirmeler. Örneğin http'den https'e, oradan www'ya ve sonra sonunda eğik çizgi olan adrese giden üç adımlı bir zincir, kullanıcı daha hiçbir şey görmeden yüzlerce milisaniye kaybettirir.

Yönlendirme zincirlerini yönlendirme denetleyici ile hızlıca görebilirsiniz. Sunucu tarafında ise sayfa önbelleği, güncel PHP sürümü ve bir CDN çoğu kurumsal sitede yeterli iyileşmeyi sağlar. Site taşıma sırasında bu ayarların kaybolmaması için site yenilerken SEO'yu koruma yazısındaki kontrol listesine de göz atın.

Erişilebilirlik, En İyi Uygulamalar ve SEO kategorileri ne anlatır?

Performans dışındaki üç kategori, sayfanın temel teknik hijyenini kontrol eder. PWA kategorisi ise Lighthouse 12 ile rapordan kaldırıldı, dolayısıyla eski rehberlerde gördüğünüz beşinci halkayı artık aramayın.

Erişilebilirlik kategorisi renk kontrastı, görsel alt metinleri, form etiketleri ve başlık sıralaması gibi maddelere bakar. En İyi Uygulamalar ise HTTPS kullanımı, konsol hataları, güvenli olmayan kütüphaneler ve doğru görsel oranları gibi konuları denetler.

SEO kategorisi temel kontrollerle sınırlıdır: title ve meta description var mı, sayfa dizine eklemeye açık mı, bağlantılarda açıklayıcı metin var mı, robots.txt geçerli mi? Eksik meta etiketlerini meta tag oluşturucu ile, robots dosyasını robots.txt oluşturucu ile hızlıca düzeltebilirsiniz.

Ancak SEO kategorisinde 100 almak iyi sıralama anlamına gelmez. Bu kategori yalnız teknik engel olup olmadığını söyler; içerik kalitesi, arama niyeti ve otorite hakkında hiçbir şey ölçmez. Daha kapsamlı teknik denetim için yapay zeka sonrası teknik SEO yazısına bakabilirsiniz.

Lighthouse testi sonrasında iyileştirme sırasını nasıl belirlersiniz?

Lighthouse testi size onlarca madde verir, fakat hepsi aynı değeri taşımaz. Ben önceliği üç soruyla belirliyorum: bu madde hangi metriği etkiliyor, tahmini kazanç ne kadar ve düzeltmek ne kadar emek istiyor?

Genellikle işe yarayan sıra şudur:

1. Saha verisinde kırmızı olan metriği bulun; önce onu çözün.
2. Ucuz ve büyük kazançları alın: lazy loading hatası, boyutsuz görseller, gereksiz betikler.
3. Sunucu ve önbellek ayarlarını düzeltin; bu işlem tüm sayfalara birden yansır.
4. Ardından tema ve eklenti kaynaklı JavaScript yükünü azaltın.
5. En son mimari kararlara geçin: tema değişimi, yeniden yazım, altyapı taşıması.

Ayrıca tek sayfayla uğraşmak yerine şablon düşünün. Ürün sayfası şablonundaki bir düzeltme yüzlerce sayfayı aynı anda iyileştirir. Bu yüzden testi ana sayfa, kategori, ürün veya hizmet ve blog şablonlarından birer örnekle yapın. Şablon mantığını büyük sitelerde nasıl kurduğumu büyük sitelerde kategori yapısı yazısında anlattım.

Lighthouse skoru 100 olmak zorunda mı?

Hayır. Skor bir hedef değil, bir göstergedir. Google Search Central'ın Core Web Vitals belgesi iyi Core Web Vitals değerlerini öneriyor, ancak sıralamada gerçek kullanıcı verisine dayanan bu metrikleri esas alıyor, Lighthouse laboratuvar puanını değil.

Pratikte gördüğüm şu: skor 65'ten 85'e çıktığında kullanıcı farkı hisseder. 92'den 99'a çıkarken ise çoğu zaman analitik etiketini, sohbet aracını veya markanın istediği görsel efekti feda etmeniz gerekir. Bu takasın iş açısından mantıklı olup olmadığını ayrıca düşünmelisiniz.

Benim önerdiğim hedef şu: saha verisinde üç Core Web Vitals metriği yeşil olsun, mobil laboratuvar skoru da mümkünse 70'in üzerinde kalsın. Bu aralık saha tecrübeme dayanan bir başlangıç noktasıdır, garanti değil. Rakiplerinizden çok daha yavaşsanız hız kesin önceliktir; zaten hızlıysanız fazladan birkaç puan yerine içerik ve dönüşüm çalışması daha çok getiri sağlar. Hangi alana öncelik vereceğinize karar vermekte zorlanıyorsanız SEO danışmanlığı kapsamında bu dengeyi birlikte kurabiliriz.

İyileştirmeyi nasıl ölçer ve korursunuz?

İyileştirme bir kerelik iş değildir. Yeni eklenti, yeni kampanya pikseli ya da büyük bir banner görseli birkaç hafta içinde skoru eski yerine döndürebilir. Bu nedenle ölçümü düzenli hale getirin.

Benim kullandığım düzen üç katmanlıdır. Birinci katman Search Console'daki Core Web Vitals raporudur; sitedeki URL gruplarının saha durumunu gösterir ve bir sorunu düzelttiğinizde doğrulama başlatmanıza izin verir. İkinci katman aylık PageSpeed Insights kontrolüdür; ana şablonları aynı günde test edip sonuçları bir tabloya yazarım. Üçüncü katman ise sık güncellenen sitelerde Lighthouse CI'dır; skor belirlenen eşiğin altına düşerse yayını durdurur.

Üstelik her değişikliği bir değişiklik günlüğüne not edin: hangi gün hangi eklenti eklendi, hangi betik kaldırıldı? Skor düştüğünde nedenini bulmanın en hızlı yolu bu günlüktür. Kısacası ölçüm ritmi, tek seferlik hızlandırmadan daha değerlidir.

Özet: Lighthouse testi için kısa kontrol listesi

Bu rehberin tamamını birkaç maddeye indirirsek, bir sonraki Lighthouse testinizde şu sırayı izleyebilirsiniz:

• Önce PageSpeed Insights'ta saha verisine bakın; kırmızı metrik varsa oradan başlayın.
• Laboratuvar testini gizli pencerede, mobil ayarla ve en az üç kez koşun.
• Skora değil, metriklere ve tahmini kazanca bakın.
• LCP için hero görselini, TBT için JavaScript yükünü, CLS için boyutsuz öğeleri kontrol edin.
• Değişiklikleri şablon düzeyinde yapın ve her birini günlüğe yazın.
• Sonuçları Search Console'da 28 günlük saha verisiyle doğrulayın.

Yeni bir site planlıyorsanız bu kuralları sonradan eklemek yerine baştan tasarıma yerleştirmek çok daha ucuzdur. Hazır bütçe aralıklarını web sitesi yaptırma fiyatları sayfasında bulabilirsiniz. Mevcut sitenizin raporunu birlikte okumak isterseniz iletişim sayfasından bana ulaşın.