Google Lighthouse Metrikleri ve Core Web Vitals Temelleri
Modern web ekosisteminde kullanıcı deneyimi ile arama motoru optimizasyonu (SEO) arasındaki çizgi tamamen ortadan kalkmıştır. Google'ın sayfa deneyimi algoritma güncellemeleri, bir web sitesinin teknik başarısını doğrudan arama motoru sıralamalarına entegre etmiştir. Google Lighthouse, bir sayfanın performansını, erişilebilirliğini, en iyi uygulamalarını ve SEO parametrelerini ölçümleyen en yetkin araçtır. Ancak bu araçta 100 tam puan elde etmek, yalnızca rastgele optimizasyon teknikleri uygulamakla değil, ölçümleme algoritmalarının matematiksel arka planını ve ağırlıklandırma modellerini kavramakla mümkündür. Yapılan kapsamlı vaka çalışmaları, yükleme süresindeki 0,1 saniyelik bir iyileşmenin e-ticaret sitelerinde dönüşüm oranlarını ortalama %8,4 artırdığını ve hemen çıkma oranlarını (bounce rate) %32 oranında düşürdüğünü açıkça doğrulamaktadır.
Lighthouse puanlaması sabit bir formül üzerinden çalışmaz; Google'ın belirlediği Core Web Vitals (Önemli Web Verileri) metriklerine göre ağırlıklandırılmış dinamik bir algoritma havuzudur. Lighthouse sürüm 10 ve sonrasında, First Input Delay (FID) metriğinin yerini alan Interaction to Next Paint (INP) ve JavaScript darboğazlarını simüle eden Total Blocking Time (TBT), puanlama matrisinin neredeyse üçte birini domine etmektedir. Bir web sayfasının Lighthouse performans skoru temel olarak beş ana metriğin ağırlıklı ortalamasından meydana gelir: First Contentful Paint (FCP) %10, Speed Index %10, Largest Contentful Paint (LCP) %25, Total Blocking Time (TBT) %30 ve Cumulative Layout Shift (CLS) %25. Bu dağılım, 100 puan hedefinde TBT, LCP ve CLS metriklerinin toplamda %80 gibi belirleyici bir ağırlığa sahip olduğunu göstermektedir.
Lighthouse Puanlama Ağırlıkları ve Algoritma Dinamikleri
Lighthouse 100 puanına ulaşabilmek için her bir metriğin milisaniye ve birim bazındaki eşik değerlerini aşmak gerekir. Örneğin, Google standartlarında kusursuz bir performans skoru alabilmek için FCP değerinin 1,8 saniyenin altında, LCP değerinin 2,5 saniyenin (ideal olarak 1,2 saniyenin) altında ve TBT değerinin 200 milisaniyeden (tam puan için 50 ms altında) az olması zorunludur. Görsel kararlılık ölçeği olan CLS puanının ise kesinlikle 0,1 eşiğinin altında tutulması, hedefin 0 olması beklenir. Bu eşiklerin milisaniye cinsinden aşılması, logaritmik bir ceza eğrisiyle puanınızın hızla 90'ın altına düşmesine yol açar.
- First Contentful Paint (FCP): Kullanıcının tarayıcıda DOM içeriğinin (metin, görsel veya beyaz olmayan tuval) ilk parçasını gördüğü andır. %10 ağırlığa sahiptir.
- Largest Contentful Paint (LCP): Kullanıcı görünüm alanındaki (viewport) en büyük içerik bloğunun (genellikle bir hero görseli, başlık veya video kapak görseli) işlendiği süredir. %25 ağırlığa sahiptir.
- Total Blocking Time (TBT): FCP ile Time to Interactive (TTI) arasında geçen, ana iş parçacığının (main thread) 50 milisaniyeden uzun süren görevlerle (Long Tasks) kilitlendiği toplam süreyi temsil eder. %30 ağırlıkla puanı en çok etkileyen bileşendir.
- Cumulative Layout Shift (CLS): Sayfanın yüklenme ömrü boyunca kullanıcı etkileşimi haricinde gerçekleşen beklenmedik görsel kaymaların kümülatif toplamıdır. %25 ağırlığa sahiptir.
- Speed Index: Sayfa içeriğinin görsel olarak ne kadar hızlı doldurulduğunu ölçümleyen görsel ilerleme skorudur. %10 ağırlığa sahiptir.
Laboratuvar Verisi (Lab Data) ve Saha Verisi (Field Data) Ayrımı
Optimizasyon sürecinde en sık yapılan kavramsal hata, Lighthouse raporlarındaki Laboratuvar Verisi (Lab Data) ile Chrome Kullanıcı Deneyimi Raporu (CrUX) tarafından toplanan Saha Verisi (Field Data) arasındaki ayrımı göz ardı etmektir. Lighthouse, geliştirici bilgisayarında veya bir sunucu üzerinde simüle edilmiş bir ağ ortamında (genellikle yavaşlatılmış 4G bağlantı ve orta segment bir mobil CPU) anlık bir test icra eder. Buna karşın Google arama algoritması, son 28 gün içinde web sitenizi gerçek cihazlarla ziyaret eden gerçek kullanıcıların 75. yüzdelik dilimini (p75) temel alır. Dolayısıyla, sentetik bir 100 puan almak harika bir mühendislik başarısı olsa da, bu durumun gerçek cihazlarda sürdürülebilir kılınması için kod tabanının donanım dostu tasarlanması şarttır.
Laboratuvar ortamında 100 puana ulaşmak, sitenizin mimarisindeki tüm darboğazları sıfırladığınız anlamına gelir. Ancak gerçek kullanıcıların eski mobil cihazlardan veya dalgalı hücresel ağlardan bağlanabileceği unutulmamalıdır. Bu nedenle optimizasyon planı oluşturulurken, yalnızca belirli bir bant genişliği optimizasyonu değil, CPU yürütme maliyeti, bellek tahsisi ve pil tüketimi gibi donanımsal parametreler de dikkate alınmalıdır. Sayfanın ilk yüklenişindeki ham byte büyüklüğünden, JavaScript motorunun ayrıştırma (parse) ve derleme (compile) sürelerine kadar her katman bir bütün olarak yapılandırılmalıdır.
LCP (Largest Contentful Paint) Optimizasyonu ve Sunucu Yanıt Süreleri
Largest Contentful Paint, modern bir web sayfasının algılanan yükleme hızının omurgasını oluşturur. Bir kullanıcının sayfaya girdiğinde gördüğü en büyük görsel veya metin bloğu ne kadar çabuk ekrana gelirse, sayfa o denli hızlı kabul edilir. Google verilerine göre LCP süresi 2,5 saniyenin altında olan web siteleri, 4 saniyenin üzerinde olan sitelere kıyasla %24 daha az terk edilme oranına sahiptir. 100 Lighthouse puanı için LCP süresini 1,2 saniyenin altına çekmek gerekir. Bunun sağlanabilmesi ise doğrudan iki ana dinamiğe bağlıdır: Sunucu Yanıt Süresi (Time to First Byte - TTFB) ve LCP kaynak yükleme önceliklendirmesi.
Sunucu yanıt süresi 600 milisaniyenin üzerinde olan bir sistemde 100 puan almak matematiksel olarak imkansızdır; hedef TTFB değeri daima 200 milisaniyenin altında olmalıdır. Dinamik PHP veya Node.js tabanlı yapılarda veritabanı sorgularının optimize edilmemesi, harici API çağrılarının senkronize yürütülmesi veya yetersiz sunucu önbelleklemesi (caching) TTFB değerini yukarı taşır. Bu sorunu çözmek için sunucu tarafında Redis veya Memcached tabanlı nesne önbelleklemesi devreye alınmalı, Nginx veya Apache katmanında FastCGI mikro önbellekleme kurgulanmalı ve web uygulaması mümkünse bir Edge Worker (Cloudflare Workers, Fastly Compute@Edge) mimarisi arkasında çalıştırılarak içerik kullanıcıya en yakın coğrafi noktadan sunulmalıdır.
Görsel Kaynaklarının Modernleştirilmesi: AVIF, WebP ve fetchpriority
Görsel medya varlıkları, modern bir web sayfasının toplam veri transferinin ortalama %60'ından fazlasını oluşturur. Eski nesil JPEG ve PNG formatları, dosya boyutu optimizasyonunda yetersiz kalmaktadır. Yeni nesil WebP ve özellikle AVIF formatları, aynı görsel kalitesinde JPEG dosyalarına kıyasla %30 ila %50 arasında kayıpsız veri tasarrufu sağlar. LCP öğesi olarak işaretlenen ana hero görseli, kesinlikle ertelenmiş yükleme (lazy loading) özniteliğine sahip olmamalıdır. Lazy load uygulanan hero görselleri, tarayıcının düzen motoru çalışana kadar yüklemeyi durdurduğu için LCP süresini doğrudan 1 ila 2 saniye geciktirir.
En yüksek LCP puanını yakalamak için hero görseli doğrudan HTML akışının en başında tarayıcıya bildirilmelidir. Bunun için HTML <head> etiketleri arasına ön yükleme (preload) yönergeleri eklenmeli ve tarayıcının kaynak indirici motoruna yüksek öncelik atayan fetchpriority="high" özelliği atanmalıdır. Örneğin aşağıdaki kod bloğu, tarayıcının diğer stil ve script dosyalarını beklemeden ana görseli doğrudan indirme kuyruğunun en tepesine almasını garanti eder:
<link rel="preload" as="image" href="/assets/hero-banner.avif" type="image/avif" fetchpriority="high">
Buna ek olarak, responsive tasarım mimarisinde mobil cihazlara masaüstü boyutunda devasa görseller indirtmek en büyük LCP suçlusudur. HTML5 <picture> etiketi veya srcset ve sizes özellikleri kullanılarak, mobil cihazlar için 480 piksel genişliğinde ve 40 KB ağırlığında, masaüstü cihazlar için ise 1440 piksel genişliğinde varyantlar servis edilmelidir. Bu adaptif yaklaşım, mobil tarayıcının gereksiz bant genişliği harcamasını önleyerek LCP değerini anında optimize eder.
Kritik CSS (Critical CSS) ve Tipografi Optimizasyonu
Tarayıcılar, harici CSS dosyalarını "render-blocking" (ekran çizimini engelleyen) kaynaklar olarak sınıflandırır. Boyutu 200 KB olan devasa bir ana stil dosyasının indirilmesi ve CSSOM ağacının oluşturulması beklenirken, LCP öğesi görsel olarak hazır olsa bile ekrana basılamaz. 100 puan hedefine ulaşmak için sayfanın ilk görünüm alanında (above-the-fold) yer alan öğeleri biçimlendiren stiller (Kritik CSS), harici dosyadan ayıklanmalı ve doğrudan HTML belgesinin içine <style> etiketleriyle gömülmelidir (inlining). Geriye kalan ikincil stil dosyaları ise asenkron olarak arka planda indirilmelidir.
Benzer bir gecikme web fontlarının yüklenişinde de yaşanır. Özel bir font ailesi (örneğin Montserrat veya Roboto) sunucudan geç indiğinde, metin LCP öğesi ise tarayıcı metni görünmez kılar (Flash of Invisible Text - FOIT). Bu durum LCP skoruna doğrudan darbe vurur. CSS font tanımlarında font-display: swap; kuralı mutlaka tanımlanmalıdır. Bu kural, tarayıcının özel font inene kadar sistem fontunu (Arial, sans-serif) göstermesini ve font indiğinde kesintisiz geçiş yapmasını sağlar. Ayrıca, font dosyaları WOFF2 formatında derlenmeli, yalnızca sitede kullanılan karakter setlerini içerecek şekilde alt kümelere (subsetting) ayrılmalı ve kritik font dosyaları için <link rel="preload" as="font" type="font/woff2" crossorigin> bildirimi yapılmalıdır.
TBT (Total Blocking Time) ve INP (Interaction to Next Paint) İyileştirme
Total Blocking Time ve yeni nesil Interaction to Next Paint, bir web sitesinin saf dosya boyutunun ötesinde, tarayıcının JavaScript motorunu nasıl tükettiğini ölçümleyen performans parametreleridir. TBT, sayfa yüklenirken kullanıcının tıklama, dokunma veya klavye girdisi yapmasını engelleyen, 50 milisaniyeden uzun süren her bir ana iş parçacığı görevini (Long Task) cezalandırır. Örneğin bir JavaScript görevi 140 milisaniye sürüyorsa, ilk 50 ms aşım sonrası kalan 90 milisaniye doğrudan TBT havuzuna eklenir. 100 Lighthouse puanı için TBT'nin kesinlikle 50 milisaniyenin altında olması gerekir. 200 ms üzeri değerler puanınızı hızla turuncu veya kırmızı bölgeye iter.
JavaScript yürütme maliyeti, cihazların donanım gücüne doğrudan bağımlıdır. Bir masaüstü i9 işlemci 1 MB JavaScript kodunu 60 milisaniyede derleyip çalıştırabilirken, piyasadaki ortalama bir bütçe dostu Android cihazda aynı işlem 1,5 saniyeden uzun sürebilir ve arayüzü tamamen dondurabilir. Lighthouse testleri zayıf bir mobil CPU profilini taklit ettiği için gereksiz JavaScript yükleri doğrudan felaket bir TBT skoruyla sonuçlanır. Bu sebeple hedef, istemciye (client) gönderilen ham JavaScript miktarını radikal bir biçimde düşürmek ve ana iş parçacığını serbest bırakmaktır.
Ana İş Parçacığını (Main Thread) Rahatlatma ve Kod Bölümleme (Code Splitting)
Monolitik ve tek parça halinde derlenen büyük JavaScript bundle yapıları, TBT ve INP metriklerinin en yaygın kaynağıdır. Modern geliştirme süreçlerinde Webpack, Vite, Rollup veya Turbopack gibi derleyiciler aracılığıyla kod bölümleme (Code Splitting) ve dinamik içe aktarma (Dynamic Imports) uygulanmalıdır. Kullanıcının o an bulunduğu sayfada ihtiyaç duymadığı modüller, ana bundle dosyasından ayrıştırılmalıdır. Örneğin bir e-ticaret sitesinde ödeme formu scriptleri sadece sepet adımında yüklenmeli; anasayfada bu kodlar asla çalıştırılmamalıdır.
Ağır hesaplama gerektiren operasyonlar veya karmaşık veri işleme süreçleri doğrudan ana iş parçacığı üzerinde çalıştırılmamalıdır. Web Workers API kullanılarak bu ağır hesaplamalar arka plan iş parçacıklarına devredilebilir. Kullanıcı arayüzünü güncelleyen kodlar ise küçük görev parçalarına (micro-tasks) bölünmeli ve tarayıcının boş anlarını kollayan requestIdleCallback() veya modern scheduler.yield() API'leri ile koordine edilmelidir. Böylece araya bir kullanıcı tıklaması girdiğinde tarayıcı donmaz, tıklamaya derhal yanıt verir ve INP değeri kusursuz seviyede kalır.
Üçüncü Taraf Komut Dosyalarının (Third-Party Scripts) Yönetimi
Birçok web sitesinde Lighthouse puanının 50-60 seviyelerinde sürünmesinin birincil faili, site sahiplerinin kontrolsüzce eklediği üçüncü taraf entegrasyonlarıdır. Google Tag Manager, Facebook Pixel, Hotjar, tawk.to canlı destek pencereleri ve reklam kütüphaneleri, ana iş parçacığını dakikalarca kilitleyebilir. Yapılan araştırmalar, ortalama bir web sayfasında çalışan üçüncü taraf kodlarının toplam JavaScript çalıştırma süresinin %57'sini tükettiğini göstermektedir. 100 puana ulaşmak, bu araçları tamamen kaldırmak anlamına gelmez; onları akıllıca orkestre etmek anlamına gelir.
- Asenkron Yükleme: Analitik ve izleme scriptleri hiçbir koşulda senkron yüklenmemelidir.
asyncveyadefernitelikleri mutlak surette kullanılmalıdır. - Cephe (Façade) Modeli Uygulaması: YouTube video oynatıcıları veya interaktif haritalar gibi ağır iframe öğeleri sayfa açılışında doğrudan yüklenmemelidir. Bunun yerine statik bir görsel ve sahte bir "Oynat" butonu yerleştirilmeli; kullanıcı butona tıkladığı anda asıl iframe dinamik olarak çağrılmalıdır. Bu teknik TBT değerini tek hamlede 400 ms aşağı çekebilir.
- Web Worker ile İzolasyon (Partytown): Üçüncü taraf takip kodları, DOM manipülasyonuna doğrudan ihtiyaç duymaz.
Partytowngibi kütüphaneler kullanılarak Google Analytics veya Meta Pixel kodları tamamen bir Web Worker içine taşınabilir ve ana iş parçacığından sıfır maliyetle izole edilebilir. - Gecikmeli Başlatma (Idle Loading): Canlı destek widget'ları gibi kritik olmayan öğeler, sayfa tamamen etkileşimli hale geldikten 3-5 saniye sonra veya kullanıcının ilk kaydırma (scroll) hareketi sonrasında tetiklenmelidir.
CLS (Cumulative Layout Shift) Sıfırlama ve Arayüz Kararlılığı
Cumulative Layout Shift, web sayfasının görsel dengesini ve yüklenme sırasındaki öngörülebilirliğini temsil eden metriktir. Bir makaleyi okurken tam bir bağlantıya tıklayacakken içeriğin aniden aşağı kayması ve kullanıcının yanlış bir reklama tıklaması, tipik bir yüksek CLS problemidir. Google, kullanıcıyı yanıltan ve etkileşim kalitesini bozan bu zıplamalara sıfır tolerans tanımaktadır. Lighthouse 100 hedefinde CLS skorunun 0,000 olması hedeflenmelidir; 0,1'in üzerindeki her değer sayfa deneyimi testinde doğrudan başarısızlık anlamına gelir.
Görsel kaymaların temel mekanizması basittir: Tarayıcı, harici bir kaynağın (görsel, video, reklam, dinamik widget) nihai boyutlarını bilmeden DOM hiyerarşisini çizer. Kaynak indikten sonra tarayıcı öğenin kapladığı gerçek alanı fark eder ve sayfanın geri kalan tüm düzenini (Reflow/Relayout) aşağı veya yana itmek zorunda kalır. Düzen motorunun bu ani yeniden hesaplaması, hem gereksiz CPU yükü üretir hem de kullanıcı deneyimini zedeler. Çözüm, tarayıcıya kaynak henüz inmeden önce kaplayacağı geometrik alanı bildirmektir.
Görseller, Medyalar ve Reklam Alanları İçin Boyut Tanımlama
CLS hatalarının en yaygın sebebi, genişlik ve yükseklik öznitelikleri belirtilmemiş görsel ve iframe öğeleridir. Modern tarayıcılar, görsellerin en-boy oranını (aspect ratio) hesaplayarak indirme gerçekleşmeden önce o alan için gereken boşluğu sayfada rezerve edebilir. Ancak bunun gerçekleşmesi için HTML etiketinde width ve height değerlerinin piksel birimi olmadan açıkça yazılması şarttır:
<img src="urun-detay.avif" width="800" height="600" alt="Ürün Detay Görseli" style="width: 100%; height: auto;">
CSS tarafında modern bir yaklaşım olarak aspect-ratio: 16 / 9; gibi kurallar kullanmak, akıcı tasarımlarda yüksekliğin doğru rezerve edilmesini garantiler. Benzer şekilde, Google AdSense veya harici reklam ağlarından çekilen dinamik reklam alanları için sabit kapsayıcı bloklar (placeholder) tanımlanmalıdır. Reklamın geleceği <div> alanına CSS ile min-height: 250px; atanmalı, böylece reklam yüklendiğinde altındaki içeriklerin aniden aşağı sıçraması engellenmelidir. Eğer reklam dönmezse, bu alanın aniden 0 piksele çökmemesi için alternatif bir yedek blok tasarlanmalıdır.
Web Font Kaynaklı Kaymalar ve Fallback Optimizasyonu
Web fontları yüklenirken iki temel davranış sergiler: FOIT (görünmez metin) veya FOUT (biçimlendirilmemiş metin parlaması). FOUT durumunda, sistem fontu (örneğin Times New Roman) ekranda belirir; saniyeler sonra özel web fontu (örneğin Montserrat) indiğinde, her iki fontun harf genişlikleri, satır yükseklikleri (line-height) ve harf aralıkları farklı olduğu için metin bloğunun kapladığı alan aniden değişir. Bu durum paragrafların genişlemesine veya daralmasına yol açarak altındaki tüm elementleri fırlatır ve devasa bir CLS artışına sebep olur.
Bu sorunu çözmek için CSS Font Metrics Override özellikleri devreye sokulmalıdır. @font-face tanımlarında fallback fontun parametreleri, asıl web fontunun ölçüleriyle birebir eşleşecek şekilde ayarlanabilir. size-adjust, ascent-override, descent-override ve line-gap-override özellikleri sayesinde, sistem fontu web fontuyla neredeyse aynı piksel alanını kaplayacak biçimde ölçeklenir. Böylece font geçiş anında ekranda tek bir piksellik bile kayma meydana gelmez ve CLS puanı kusursuz bir sıfırda kalır.
Gelişmiş Önbellekleme, Ağ Optimizasyonu ve Modern Dağıtım Mimarisi
Tüm kod optimizasyonları ve varlık sıkıştırmaları eksiksiz yapılsa bile, verinin sunucudan tarayıcıya iletildiği ağ katmanı (network layer) verimsiz yapılandırılmışsa 100 Lighthouse puanına ulaşılamaz. Sayfa performansının sürdürülebilirliği, sunucu yapılandırması, sıkıştırma algoritmaları ve gelişmiş HTTP protokollerinin entegrasyonuyla doğrudan ilintilidir. Modern bir web altyapısı, veriyi sadece küçültmekle kalmamalı; onu kullanıcının cihazına en az gecikmeyle (latency) ulaştıracak modern ağ standartlarını kullanmalıdır.
Geleneksel web sitelerinde yaygın olarak kullanılan Gzip sıkıştırma algoritması, günümüz gereksinimleri için yetersizdir. Google tarafından geliştirilen Brotli sıkıştırma algoritması, metin tabanlı dosyalarda (HTML, CSS, JS, SVG) Gzip'e kıyasla ortalama %15 ila %25 daha yüksek sıkıştırma oranı sunar. Sunucu katmanında (Nginx, Caddy, Cloudflare) Brotli sıkıştırmasının aktif edilmesi, transfer edilen toplam veri miktarını radikal bir şekilde düşürür. Bu durum FCP ve LCP sürelerini doğrudan pozitif yönde etkiler.
HTTP/3 (QUIC) ve Akıllı Önbellek (Cache-Control) Stratejileri
HTTP/1.1 protokolünün getirdiği tek kanal kısıtlaması (Head-of-Line Blocking) tarihe karışmıştır. HTTP/2 ile gelen çoğullama (multiplexing) avantajı, günümüzde yerini UDP tabanlı HTTP/3 (QUIC) protokolüne bırakmıştır. HTTP/3, paket kaybının yaşandığı mobil ağlarda bağlantı kopmalarını ve yeniden el sıkışma gecikmelerini minimize eder. Web sunucunuzun HTTP/3 desteğine sahip olması, mobil cihazlardan yapılan isteklerin ağ el sıkışma sürelerini %30'a varan oranlarda hızlandırır.
Statik kaynakların tarayıcı önbelleğinde saklanması için kusursuz bir Cache-Control politikası kurgulanmalıdır. Dosya isimlerinde hash veya sürüm numarası bulunan (örneğin bundle.a8f9c1.js) tüm JavaScript, CSS ve görsel dosyaları için önbellek süresi bir yıl olarak tanımlanmalı ve dosyanın hiçbir zaman değişmeyeceğini belirten immutable direktifi eklenmelidir:
Cache-Control: public, max-age=31536000, immutable
Dinamik HTML içerikleri için ise stale-while-revalidate stratejisi benimsenmelidir. Bu strateji sayesinde tarayıcı, arka planda sunucudan yeni içeriği çekerken kullanıcıya önbellekteki mevcut içeriği anında sunar. Böylece kullanıcı sıfır milisaniyelik bir gecikmeyle sayfaya erişmiş olur.
Kaynak İpuçları (Resource Hints) ve CI/CD Süreçlerinde Lighthouse Entegrasyonu
Tarayıcının bir sonraki adımda ne yapacağını öngörmek, sayfa hızını zirveye taşıyan ileri düzey bir yaklaşımdır. Harici domainlerden kaynak çeken siteler (örneğin font sunucuları veya CDN ağları), DNS çözümlemesi ve TLS el sıkışması gibi işlemlerle vakit kaybeder. HTML belgesine eklenecek kaynak ipuçları ile bu işlemler önceden başlatılabilir:
dns-prefetch: Gelecekte ihtiyaç duyulacak üçüncü taraf domainlerin DNS sorgularını arka planda erkenden çözümler.preconnect: Yalnızca DNS'i değil, TLS el sıkışmasını ve TCP bağlantısını da kurarak zaman kazandırır. Örneğin harici Google Fonts API'si için mutlaka kullanılmalıdır:<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>.prerendervespeculation rules: Kullanıcının tıklaması muhtemel bir sonraki sayfayı arka planda tamamen render ederek, tıklama anında sayfanın sıfır saniyede açılmasını sağlayan modern bir API standardıdır.
Web performans optimizasyonu tek seferlik bir proje değil, sürekli korunması gereken bir mühendislik disiplinidir. Bir web sitesi 100 puana ulaştıktan sonra, eklenen tek bir kontrolsüz pazarlama scripti veya optimize edilmemiş 5 MB büyüklüğünde bir görsel puanı anında 50 seviyesine düşürebilir. Bu performans gerilemelerini (performance regression) önlemek adına, yazılım geliştirme yaşam döngüsüne Lighthouse CI (LHCI) entegre edilmelidir. GitHub Actions veya GitLab CI süreçlerinde her yeni kod güncellemesinde otomatik Lighthouse testleri koşturulmalı; belirlenen performans bütçesi (örneğin JS boyutu < 150 KB, TBT < 50 ms, Lighthouse skoru > 95) aşıldığında derleme işlemi durdurulmalıdır. Bu otomasyon, sitenizin Google gözündeki kusursuz 100 puanını ve SEO liderliğini kalıcı olarak teminat altına alır.