Lighthouse Skoru Neden Yeterli Değildir: Lab vs Field Veri Gerçeği

1. Lighthouse Nedir, Ne Değildir

Temel Kavram

Lighthouse, Google'ın Chrome DevTools içine entegre ettiği açık kaynaklı bir denetim aracıdır. Performance, Accessibility, Best Practices, SEO ve PWA kategorilerinde sayfanızı puanlar. Tasarımı itibariyle sentetik bir testtir: belirli bir cihaz simülasyonu (varsayılan olarak Moto G Power benzeri orta seviye Android), kısıtlanmış bir ağ profili ve laboratuvar koşullarında tek bir koşu sonucu üretir. Bu yönüyle Lighthouse, sahada gerçek kullanıcıların yaşadığı deneyimi değil, kontrollü bir reprodüksiyonu ölçer.

Lighthouse'un asıl gücü "geliştirme sırasında erken uyarı sistemi" olmasıdır. Bir özellik yayına alınmadan önce ekibin görebileceği, tekrarlanabilir bir denetim sunar. Ancak bu rapor, sitenin gerçek dünyadaki performansının kanıtı değildir. Aracın kendisi bile bunu açıkça söyler: rapor başlığında "These results may differ from field data" notu yer alır. Bu uyarıyı görmezden gelmek, performans çalışmalarındaki en büyük kör noktalardan biridir.

Lighthouse'un bir diğer iyi yönü, actionable önerilerdir. Hangi resmin dönüştürülmesi gerektiğini, hangi JavaScript paketinin bölünmesi gerektiğini, hangi CSS bloğunun unused olduğunu net biçimde söyler. Bu öneriler, performans iyileştirmesinin başlangıç noktası olarak değerli; ancak iyileştirmenin işe yarayıp yaramadığını yalnızca lab koşullarında ölçmek yetmez. Sahadaki etki, ayrı bir kaynaktan doğrulanmalıdır.

Lighthouse'un olmadığı bir şey ise kullanıcı temsiliyetidir. Tek bir cihaz, tek bir bağlantı, tek bir coğrafi nokta ve tek bir sayfa görüntüleme üzerinden çıkardığı sonuç, milyonlarca farklı kombinasyonda ziyaret yapan gerçek trafiğin yerini tutamaz.

2. Lab Veri ve Field Veri Farkı

Olmazsa Olmaz

Web performansı evreninde iki büyük veri türü vardır: lab veri ve field veri. Lab veri, kontrollü koşullarda yapay olarak üretilen ölçümlerdir. Lighthouse, WebPageTest, PageSpeed Insights'in lab kısmı, sentetik monitoring araçları bu kategoride yer alır. Field veri ise gerçek kullanıcıların gerçek cihazlarında, gerçek bağlantı koşullarında yaşadığı deneyimden toplanan telemetridir. Lab "ne olabilir", field "ne oluyor" sorusunu yanıtlar.

Bu iki dünya arasındaki temel farklar şu boyutlarda kendini gösterir:

• Tekrarlanabilirlik: Lab veri, aynı koşullarda tekrar tekrar aynı sonucu verir. Field veri, kullanıcıdan kullanıcıya, dakikadan dakikaya değişir.
• Örneklem: Lab veri tek bir koşudur; field veri binlerce, milyonlarca ölçümün dağılımıdır.
• Bağlam: Lab, A noktasından B noktasına ilk yüklemeyi ölçer. Field, bfcache geri dönüşlerini, prefetch'lenmiş gezinmeleri, donmuş sekmeleri, sayfa içi etkileşimi de yakalar.
• Karar değeri: Lab, sürüm sırasında regresyon yakalamak için ideal. Field, gerçek kullanıcı memnuniyetini ve Google sıralama sinyalini değerlendirmek için zorunlu.

Google'ın resmi dokümantasyonu bile bu ayrımı açıkça yapar: Core Web Vitals'ı Search Console üzerinden ölçen mekanizma yalnızca CrUX field verisini dikkate alır. Lighthouse'unuz mükemmel olsa bile field verinizde LCP "Poor" eşiğindeyse Google'ın gözünde siteniz yavaştır. Sıralamayı belirleyen, lab puanı değil, gerçek kullanıcıların yaşadıklarıdır.

Bu farkı pratikte yaşayan onlarca müşterimiz oldu. Bir e-ticaret sitesi laboratuvar testlerinde 96 Performance skoru alıyor, ancak CrUX raporunda LCP p75 değeri 4.1 saniyede takılıyordu. Sebep, lab koşulunda hiç tetiklenmeyen, kullanıcı oturumu açıkken yüklenen kişiselleştirme JavaScript'iydi. Bu durum yalnızca field veriyi incelediğimizde ortaya çıktı.

3. Sentetik Testlerin Yapısal Limitleri

Kritik Uyarı

Lighthouse gibi sentetik araçlar belirli varsayımlar üzerine kuruludur. Bu varsayımlardan herhangi biri sahada bozulduğunda, lab raporu sahanın kötü bir tahmincisi haline gelir. Sentetik testlerin tipik yapısal limitleri şunlardır:

Sabit cihaz profili: Lighthouse mobil testlerinde 4x CPU throttling ile orta seviye bir Android cihazı taklit eder. Gerçek kullanıcılarınızın %30'u eski bir Android, %25'i yeni nesil iPhone, %15'i tablet, geri kalanı düşük segment cihaz kullanıyor olabilir. Bu çeşitliliği tek bir cihaz profili yansıtamaz.

Yapay ağ koşulları: "Slow 4G" simülasyonu, 1.6 Mbps download ve 750 ms RTT ile yaklaşık bir yavaş bağlantıyı taklit eder. Türkiye'de gerçek mobil bağlantıların büyük çoğunluğu çok daha hızlı çalışır; ancak metroda, asansörde, dağ köyünde, sınır bölgesinde tamamen farklı koşullar vardır. Sentetik test bu spektrumu kapsamaz.

Soğuk önbellek varsayımı: Lighthouse her koşusunda boş cache ile başlar. Oysa sahadaki kullanıcıların önemli bir kısmı dönüş ziyaretçisidir; statik içerik zaten önbellektedir. Lab değeri pesimist, field değeri çoğu zaman daha iyi olur. Bazı durumlarda ise tam tersi: lab boş cache'le çalışırken bfcache, prefetch, service worker gibi mekanizmalar field tarafında ekstra çeşitlilik üretir.

Tek sayfa görüntüleme: Lighthouse tek bir URL'i tek seferde ölçer. Gerçek kullanıcı yolculuğu çoğunlukla bir akıştır: anasayfa, kategori, ürün, sepet, ödeme. Bu akışta soft navigation, prefetch ve cache devreye girer. Sentetik test bu akışı yakalamaz.

Etkileşim eksikliği: Lighthouse sayfa açılışından sonra etkileşim simülasyonu yapmaz. INP gibi metrikler için lab tarafında "Total Blocking Time" gibi proxy metrikler kullanılır. INP, ancak gerçek kullanıcının tık, dokunuş, klavye etkileşimleri sırasında ölçülebilir. Lab'da INP'yi doğrudan ölçemezsiniz; yalnızca tahmin edersiniz.

Bu limitleri kabul ettiğinizde sentetik test bir başlangıç noktası olur, son söz olmaz.

4. CrUX: Chrome'un Gerçek Veri Hazinesi

Modern Altyapı

Chrome User Experience Report (CrUX), Google'ın Chrome tarayıcısı üzerinden anonim olarak topladığı, opt-in field veri kaynağıdır. CrUX'un kapsamı oldukça geniştir: dünyada milyonlarca site için LCP, INP, CLS, TTFB ve FCP dağılımlarını saklar. PageSpeed Insights'taki "Field Data" bölümü, Search Console Core Web Vitals raporu ve CrUX Dashboard'un kaynağı budur.

CrUX'un güçlü yönleri:

• Maliyet sıfır: CrUX'a erişmek için herhangi bir RUM çözümüne para ödemenize gerek yok.
• Google ile aynı veri: Search sıralamasında dikkate alınan veri tam olarak budur; siz de aynı kaynaktan bakarsınız.
• Karşılaştırma: Sitenizi sektör benchmark'larıyla karşılaştırma imkanı sağlar (özellikle HTTP Archive verisi ile birlikte).
• Geçmiş veri: 28 günlük rolling pencere ile trendleri görme imkanı.

CrUX'un sınırları:

• Yalnızca Chrome: Safari, Firefox ve diğer tarayıcı kullanıcıları kapsam dışı.
• Yalnızca yeterli trafiğe sahip URL'ler: Düşük trafiğe sahip sayfalar veri eşiğini geçemediği için raporda görünmez.
• 28 günlük geri görüş: Anlık değişimi yakalamaz; bir performans regresyonunun CrUX'ta görünmesi haftalar alabilir.
• Sayfa düzeyi tek metrik: Belirli bir kullanıcı segmentini ayrı izleyemezsiniz.

CrUX, Search Console üzerinden geldiği için SEO ekiplerinin doğrudan bakması gereken kaynaktır. Sentetik test ne kadar iyi olursa olsun, CrUX kötüyse Google sizi yavaş bilir. Bu yüzden Antalya'daki Fatih Web Tasarım ekibi olarak müşterilerimizin Search Console raporlarını haftalık takip ederiz; lab puanı değişmemiş olsa bile field tarafında bir dalgalanma olduğunda hemen kök neden analizine geçeriz.

5. RUM ile Sahada Ne Oluyor

İleri Düzey

Real User Monitoring (RUM), kendi sitenize entegre ettiğiniz hafif bir JavaScript ile gerçek ziyaretçilerden ölçüm toplamanızı sağlayan yaklaşımdır. CrUX'tan farkı, tüm tarayıcıları kapsamasıdır; ayrıca kendi segmentlerinizi, kullanıcı niteliklerinizi ve özel iş metriklerinizi bu veriye bağlayabilirsiniz. RUM, lab ile field arasındaki boşluğu en hassas dolduran yöntemdir.

Modern bir RUM çözümü şu boyutlarda veri toplar:

• Core Web Vitals: LCP, INP, CLS değerlerinin gerçek dağılımı
• Cihaz ve OS: iPhone 15, Galaxy A52, Pixel 8, Windows 11 gibi kırılımlar
• Bağlantı tipi: 4G, 5G, Wi-Fi, kablo
• Coğrafya: Şehir, ülke, ISP düzeyinde dağılım
• Sayfa tipi: Anasayfa, ürün, blog, sepet gibi grupların ayrı analiz edilmesi
• Etkileşim bağlamı: Hangi butona tıklandığında INP zayıfladığını gösteren olay düzeyi telemetri

RUM kurarken seçenekler geniş: web-vitals kütüphanesini kendi backend'inize bağlamak, SpeedCurve, Sentry Performance, Datadog RUM, New Relic Browser, Akamai mPulse, Cloudflare Web Analytics, Vercel Speed Insights gibi hazır çözümleri kullanmak. Kendi ihtiyaçlarınıza ve bütçenize göre seçim yaparken iki kritik soruyu sorun: Bu RUM çözümü kendisi siteyi yavaşlatıyor mu? Toplanan veri, gizlilik düzenlemelerine uygun mu?

Pratikte gördüğümüz desen şu: RUM kurulduktan sonra Lighthouse'da göremediğimiz birçok soruna ışık tutuluyor. Üçüncü taraf chat widget'ı belli saatlerde INP'yi kötüleştiriyor, belli bir mobil tarayıcıda hero görseli çok geç yükleniyor, belirli bir kampanya sayfası CLS açısından sorunlu. Bu içgörüler sentetik testte hiçbir zaman yüzeye çıkmaz.

6. Lighthouse 100 Alıp Yavaş Olan Siteler

UX Detay

Lighthouse'da mükemmele yakın puan alıp sahada zayıf performans gösteren site profili o kadar yaygın ki, sektörde "vanity score" terimi türemiş durumda. Lighthouse 98, 99 ya da 100 alan ancak gerçek dünyada kullanıcıyı zorlayan yaygın senaryolar şunlardır:

Senaryo 1: Cookie consent ve A/B test scriptleri. Lighthouse genellikle DevTools'tan inkognito modda çalıştırılır; bazı consent çerçeveleri, A/B test araçları, kişiselleştirme motorları yalnızca üretim ortamında belirli koşullarda yüklenir. Lab'da yoklar; field'da kullanıcıyı ilk üç saniye bekletirler. Sonuç: lab LCP 1.8 saniye, field LCP 4.2 saniye.

Senaryo 2: Geç enjekte edilen reklam paketleri. Bir haber sitesinde Lighthouse skoru 95 olduğu halde, gerçek kullanıcılar 6 saniyelik bir gecikme yaşıyordu. Sebep, sayfanın yüklenmesinden sonra reklam SSP'sinin (supply side platform) yüklediği iframe zinciri ve bunların oluşturduğu layout shift'lerdi. Bu CLS, Lighthouse'un üç saniyelik ölçüm penceresinde görünmüyordu.

Senaryo 3: Personalize edilmiş içerik ve oturum bağımlı yükler. E-ticaret sitelerinde oturum açmış kullanıcı için sepet sayısı, son görülen ürünler, öneri carousel'i gibi bileşenler sunucudan getirilir. Lighthouse her zaman oturum açmamış ziyaretçi olarak çalışır; oturum açmış kullanıcı deneyimini ölçmez.

Senaryo 4: Coğrafi mesafe ve TTFB. Lighthouse aracı yerel makinanızda çalıştığında TTFB minimumdadır. Ancak Türkiye'deki kullanıcı, sitenin sunucusu Frankfurt'taysa 60-80 ms ek RTT yaşar. CDN doğru yapılandırılmamışsa bu fark 200 ms'ye kadar çıkar. Field LCP doğal olarak kötüleşir.

Senaryo 5: Ağır INP'li bileşenler. Lighthouse sayfa açılışını ölçer; kullanıcı arama kutusuna yazdığında, filtre menüsünü açtığında, sepete ekle butonuna bastığında ne olduğunu ölçmez. Mağaza içi arama, çok aşamalı form, harita filtreleme gibi etkileşim ağırlıklı sayfalarda lab puanı yalan söyler. Sahadaki INP rakamı bambaşkadır.

Bu senaryoların ortak teması: Lighthouse "sayfa indi" anına bakar; sahada kullanıcı "sayfayı kullanabilirim" hissine ulaşana kadar yaşananları ölçer. Bu iki an arasında 4-5 saniyelik bir uçurum olabilir.

7. Cihaz, Ağ ve Coğrafya Çeşitliliği

Olmazsa Olmaz

Türkiye gibi geniş ve heterojen bir pazarda kullanıcı tabanınız tek tip değildir. Bir kurumsal müşterimizin RUM verisinde gördüklerimiz oldukça çarpıcıydı:

• Ziyaretlerin %48'i son üç yılda çıkmış mobil cihazlardan, %22'si 4-6 yaşında cihazlardan, %30'u masaüstünden geliyordu.
• Mobil bağlantıların %65'i 4G, %22'si 5G, %13'ü Wi-Fi'di. 5G payı son altı ayda iki kat arttı.
• Coğrafi dağılım İstanbul (%34), Ankara (%14), İzmir (%9), Antalya (%8) ve geri kalan tüm iller (%35) olarak şekilleniyordu.
• Mobil cihazlarda ortalama LCP 2.9 saniye iken, eski Android cihazlarda 5.4 saniyeyi buluyordu.

Lighthouse tek bir cihaz, tek bir bağlantı, tek bir coğrafya simüle eder. Bu cihazların hangisi gerçeğinizdir? Hiçbiri ve hepsi. Performansı doğru anlamak için kullanıcı tabanınızın çeşitliliğini kabul etmek ve persentil tabanlı düşünmek gerekir.

Google'ın resmi tavsiyesi p75 (yüzde 75) metriği kullanmaktır. Yani ziyaretçilerinizin %75'inin yaşadığı veya daha iyi olan değer eşiği. Median (p50) çoğu zaman aldatıcıdır; "ortalama kullanıcı" iyi bir deneyim yaşıyor olsa bile uçta kalan %25 kayıp gider. Ortalama LCP 2.4 saniye olabilir; p75 değeri 4.6 saniye olabilir. Karar verirken p75'e bakın.

Bu çeşitlilik perspektifi, yalnızca lab odaklı geliştirme yapan ekiplerin sıklıkla atladığı bir noktadır. Yeni nesil MacBook'ta her şey hızlıdır; Türkiye'nin Doğu Anadolu illerinde 4G bağlantıdaki Galaxy A serisi kullanıcısı için aynı sayfanın yüklemesi 6 saniyeyi bulabilir.

8. Üçüncü Taraf Script Sürprizleri

Kritik Risk

Modern bir kurumsal site genellikle 8-25 arası üçüncü taraf script taşır: Google Tag Manager, Analytics, Meta Pixel, TikTok Pixel, chat widget, A/B test SDK'sı, ısı haritası, anket aracı, CDP, push notification SDK'sı, kişiselleştirme motoru, reklam paketleri... Bu scriptlerin önemli bir kısmı Lighthouse koşusu sırasında bazen yüklenir, bazen yüklenmez. Üretimde her zaman yüklenir.

Üçüncü taraf script'lerin tipik etkileri:

• Ana thread bloklama: 200-400 ms süren JavaScript yürütmeleri INP'yi kötüleştirir.
• Beklenmedik layout shift: Banner, popup veya consent widget'ı geç gelince CLS yükselir.
• DNS / TLS overhead: Her yeni alan adı için bağlantı kurmak ek 50-150 ms maliyet getirir.
• Cascading load: Bir scriptin başka scriptleri çağırması, network waterfall'u uzatır.
• Üretim-özel davranış: A/B test SDK'sı yalnızca üretim alan adında aktiftir; lab'da görünmez.

Bu yüzden lab ölçümlerinizi gerçekçi tutmanın en hızlı yolu, mümkünse Lighthouse'u üretim URL'i üzerinde, gerçek consent kabul senaryosuyla çalıştırmaktır. PageSpeed Insights üretim URL'inize bakarak hem lab hem field tarafında ne olduğunu yan yana gösterir; iki sütun arasındaki uçurum kendinizi avutmanıza izin vermez.

Antalya'da çalıştığımız bir hizmet sektörü müşterisinde, Lighthouse skorunu 75'ten 95'e çıkardık. Ancak field LCP değeri sadece 200 ms iyileşti. Sebebini araştırdık: temel sayfa hızı düzelmişti, ama yeni eklenen WhatsApp Business chat widget'ı her ziyarette 1.6 saniye ek yük üretiyordu. Widget'ı async loader ile geç çağrıya aldığımızda field LCP 1.8 saniye iyileşti. Tek bir RUM dashboard'u, Lighthouse'un göstermediği gerçek hikayeyi anlattı.

9. Kullanıcı Etkileşim Senaryoları

UX Detay

Web performansını yalnızca sayfa açılışıyla ölçmek 2026 standartlarında yetersizdir. Kullanıcı bir sayfayı açtıktan sonraki etkileşim akışı (arama kutusu, filtre menüsü, sepete ekleme, slider çalıştırma) en az ilk yükleme kadar kritik. Bu yüzden Google 2024'te FID'yi kaldırıp INP'yi Core Web Vitals'a aldı.

INP'nin önemli olduğu yerler genellikle sentetik testin görmediği durumlardır:

• Arama otomatik tamamlama: Her harfle birlikte 80-300 ms işlem süresi
• Filtre menüleri: Bir checkbox tıklandığında 200+ ürün listesinin yeniden render edilmesi
• Modal açılışları: Karmaşık form bileşenlerinin lazy yüklenmesi sırasında main thread tıkanması
• Sepete ekle: Lokal state, optimistic UI, fetch, popup zinciri
• Çoklu adım form: Doğrulama, alan animasyonu, ileri buton tepkisi

Bu etkileşimleri lab'da yakalamak için user flow tabanlı Lighthouse testleri yazabilirsiniz. Lighthouse CLI ve lighthouse-flow API'si ile sayfa açılışından sonra script ile gezilen senaryoları ölçmek mümkün. Yine de bu testler ancak sizin yazdığınız adımları kapsar; gerçek kullanıcının yapmadığını siz hayal edemezsiniz. RUM bu yüzden tartışmasız üstündür: kullanıcının ne yaptığını öğrenmek için tahmin etmenize gerek kalmaz.

INP iyileştirme stratejileri içinde en çok geri dönüş aldığımız teknikler şunlar oldu: ana thread'de uzun süren işleri scheduler.yield() ile bölmek, dinamik bileşenleri requestIdleCallback içinde başlatmak, üçüncü taraf scriptleri Partytown gibi web worker tabanlı çerçevelere taşımak ve görsel DOM'larını content-visibility: auto ile lazy render etmek.

10. Sürekli İzleme ve Performans Bütçesi

Modern Altyapı

Performans tek seferlik bir proje değildir; sürdürülen bir disiplindir. Bugün düzelttiğiniz LCP, üç hafta sonra yeni bir kampanya banner'ı veya yeni bir analytics scripti yüzünden bozulabilir. Bu yüzden modern web ekipleri performans bütçesi tanımlar ve bu bütçeyi otomatik olarak CI/CD pipeline'ında uygular.

İyi bir performans bütçesi şu boyutları içerir:

• JavaScript bütçesi: Anasayfada toplam <200 KB gzipped, üçüncü taraf dahil <350 KB
• CSS bütçesi: Kritik CSS <14 KB, toplam <80 KB
• Görsel bütçesi: Hero görsel <120 KB, sayfa toplamı <800 KB
• Font bütçesi: Maksimum 2 font, 4 weight, WOFF2 formatında
• İstek bütçesi: Sayfa başına <65 HTTP isteği
• Field metrik bütçesi: LCP p75 <2.5s, INP p75 <200ms, CLS p75 <0.1

Bu bütçeyi uygulamanın iki ayağı var: preventive (önleyici) ve detective (tespit edici). Önleyici tarafta Lighthouse CI, Webhint, Bundle Analyzer ile her PR'da regresyonları yakalarsınız. Tespit edici tarafta ise RUM dashboard'unuza alarm kurarsınız: LCP p75 2 gün üst üste 2.8 saniyeyi geçtiğinde Slack uyarısı düşer. Bu iki katmanın birlikte çalışması, performansı sürdürülen bir disiplin haline getirir.

Antalya'daki Fatih Web Tasarım ekibi olarak kurumsal müşterilerimize teslim ettiğimiz her projede performans bütçesi taahhüdü veriyoruz. Sözleşmede tanımlı eşikler altında kalmadığımızda devreye giren bir düzeltme süreci işliyor. Bu disiplin, lab puanı odaklı düşünen ajansların sunmadığı bir hizmettir.

11. Lighthouse, CrUX ve RUM'u Birlikte Kullanmak

İleri Düzey

Lighthouse'un yetersizliğini kabul etmek, "Lighthouse'u bırakın" demek değildir. Üç kaynağı bütünleşik bir gözlemlenebilirlik kümesi olarak kullanmak en sağlıklı yaklaşımdır:

Lighthouse (lab): Her PR'da otomatik koşulan regresyon detektörü. CI'da lighthouse-ci aracı ile bütçe aşan değişiklikleri build'i kırma seviyesinde uyarın.

CrUX (field, Chrome): Google'ın gözünden sitenizin nasıl göründüğünü gösterir. Search Console üzerinden raporları haftalık takip edin. URL grupları (origin, page) düzeyinde alarm kurun.

RUM (field, tüm tarayıcılar): Tüm kullanıcı tabanınızdan gerçek zamanlı veri. Cihaz, ağ, coğrafya, sayfa tipi, kullanıcı segmenti bazında derin analiz. Lab'da ve CrUX'ta görünmeyen anomalileri ortaya çıkarır.

Bu üçlünün birlikte kullanımı şu pratik döngüyü doğurur:

• RUM bir anomali işaret eder (örnek: belirli bir sayfada INP p75 zıplaması)
• Lab'da reprodüksiyon yapılmaya çalışılır (Lighthouse, WebPageTest, Chrome DevTools Performance)
• Kök neden bulunur ve düzeltme yapılır
• Lab tarafında bütçe testi geçirilir
• Yayına alındıktan sonra RUM tekrar kontrol edilir ve CrUX'un trendi izlenir

Bu döngü, lab odaklı çalışan ekiplerin sıklıkla atladığı şeyi otomatize eder: iyileştirmenin sahada gerçekten yaşandığını doğrulamak. Bir değişikliğin lab tarafında işe yaradığını görmek ile gerçek kullanıcılara fayda sağladığını görmek arasında çok büyük bir fark vardır.

12. Antalya'dan Türkiye'ye: Pratik Yol Haritası

Modern Altyapı

Kurumsal bir web sitesinin Lighthouse odaklı performans yönetiminden, lab + field bütünleşik bir izleme kültürüne geçişi için önereceğimiz pratik yol haritası şu adımlardan oluşur:

Hafta 1 - Mevcut durum tespiti: PageSpeed Insights ile origin ve kritik sayfalar için lab ve field raporları alın. Search Console üzerinden Core Web Vitals raporunu inceleyin. CrUX Dashboard'da son 90 günlük trendi görün. Mevcut sentetik test araçlarının (varsa) konfigürasyonunu değerlendirin.

Hafta 2 - RUM kurulumu: web-vitals kütüphanesini kendi backend'inize yazdırma veya hazır bir RUM çözümü entegre etme. Veri akışını doğrulayın. Gizlilik politikası ve KVKK uyumunu kontrol edin. İlk 7 günlük baz verileri toplayın.

Hafta 3 - Performans bütçesi tanımı: Sayfa tiplerine göre ayrı bütçe tanımı (anasayfa, ürün, kategori, blog). Hem lab bütçesi (JS, CSS, image, font, request) hem field bütçesi (LCP p75, INP p75, CLS p75). Bu bütçeyi Lighthouse CI ve RUM alarm'larına entegre edin.

Hafta 4 - İlk dalga iyileştirmeler: RUM ve CrUX'tan gelen ilk içgörüler doğrultusunda en yüksek etkili 3-5 değişikliği uygulayın. Genellikle bunlar şu kategoride yer alır: hero görsel optimizasyonu, render-blocking script ayrıştırması, üçüncü taraf widget'ı geciktirme, font yüklemesi.

Sonrası - Sürdürülebilir döngü: Her ay performans review toplantısı. RUM dashboard'unda trend incelemesi. Yeni özelliklerin bütçe içinde kalıp kalmadığının test edilmesi. Performans regresyonlarının kök neden analizi.

Antalya merkezli bir web tasarım ajansı olarak Türkiye genelinde hizmet veriyor olmamızın bir avantajı, bu yol haritasını kurumsal müşterilerimize uzaktan ya da hibrit olarak baştan sona uygulayabiliyor olmamız. İletişim formumuz üzerinden bize ulaşan markalar için ilk teknik denetimi ücretsiz olarak yapıyoruz. Hem mevcut Lighthouse skorlarınızı hem de CrUX field verinizi yan yana koyup gerçek performans hikâyenizi birlikte okuyoruz.

Sonuç: Sayı Değil Deneyim Önemli

Lighthouse skorunu sıfırdan 90'a çıkarmak teknik olarak gerçek bir başarı sayılabilir; ancak gerçek başarı, kullanıcılarınızın sitenizde geçirdiği zamanın kalitesinde ölçülür. Bir e-ticaret müşterimizin Lighthouse skoru hiç değişmeden, sadece field tarafında yaptığımız iyileştirmelerle dönüşüm oranı %18 arttı. Skor değişmedi; deneyim değişti. Önemli olan, kullanıcının sayfayı kullanılabilir hissetmesi, butona dokunduğunda hızlı yanıt almasıdır.

Modern web performansı kültürü üç ayak üzerinde durur: lab'da bütçe disiplini, CrUX'ta SEO görünürlüğü ve RUM'da gerçek kullanıcı içgörüsü. Bu üç kaynaktan biri eksikse karar verme süreciniz kör nokta üretmeye mahkumdur. Fatih Web Tasarım olarak kurumsal müşterilerimize bu üç ayağı kuran ve sürdüren projeler teslim ediyoruz. Sitenizin sayılarla değil deneyimle ölçüldüğü bir yapıya geçmek isterseniz bizimle iletişime geçin; ilk değerlendirme görüşmesi ücretsiz.

Son olarak vurgulamak istediğimiz nokta şu: Lighthouse aleyhine bir manifesto yazmıyoruz. Bu araç, doğru yerde doğru zamanda kullanıldığında değerlidir. Sorun, ona hak ettiğinden fazla anlam yüklendiğinde başlar. Yöneticilerin "Lighthouse 100 alalım" hedefini ekibe vermesi, asıl iş olan kullanıcı deneyimini perdeleyen bir uğraşıya dönüşebilir. Onun yerine "field LCP p75 değerini 2.5 saniyenin altına çekelim ve orada tutalım" gibi sahaya bakan hedefler belirlemek, ekibi gerçekten önemli olana yönlendirir. Bu kültürel dönüşüm, çoğu zaman teknik dönüşümden daha büyük etki üretir; çünkü ekibin enerjisini ve zaman bütçesini yeniden organize eder. Antalya'dan tüm Türkiye'ye taşıdığımız bu yaklaşım, kurumsal müşterilerimizin uzun vadeli performans kazanımlarının da temelini oluşturur.