Sayfa hızı ve kullanıcı deneyimi dünyasına adım attığınızda karşınıza yüzlerce İngilizce kısaltma ve teknik terim çıkar: LCP, CLS, INP, TTFB, TBT, CrUX, p75… Her birinin kendine özgü bir ölçüm mantığı, eşik değeri ve SEO’ya doğrudan yansıyan sonuçları vardır. Google’ın Page Experience güncellemiyle bu kavramlar artık yalnızca geliştiricilerin değil, SEO uzmanlarının, içerik yöneticilerinin ve dijital pazarlama profesyonellerinin günlük kelime dağarcığında yer almaktadır.
Bu sözlük, Core Web Vitals ekosistemindeki her terimi Türkçe olarak, derinlemesine ve ölçülebilir eşik değerleriyle birlikte açıklamak için hazırlandı. Terimler mantıksal gruplara ayrılmış; her başlık, kavramın ne anlama geldiğini, nasıl ölçüldüğünü, neden önemli olduğunu ve hangi değerlerin “iyi”, “geliştirilmeli” veya “kötü” sayıldığını netleştirir. İster LCP’yi ister CLS’yi ister INP’yi araştırıyor olun; bu sayfa başvuru kaynağınız olmak üzere tasarlandı.
Tüm Metrikler için Hızlı Eşik Tablosu
| Metrik | İyi | Geliştirilmeli | Kötü |
|---|---|---|---|
| LCP | < 2.5 sn | 2.5 – 4.0 sn | > 4.0 sn |
| CLS | < 0.1 | 0.1 – 0.25 | > 0.25 |
| INP | < 200 ms | 200 – 500 ms | > 500 ms |
| FID | < 100 ms | 100 – 300 ms | > 300 ms |
| TTFB | < 800 ms | 800 ms – 1.8 sn | > 1.8 sn |
| FCP | < 1.8 sn | 1.8 – 3.0 sn | > 3.0 sn |
| TBT | < 200 ms | 200 – 600 ms | > 600 ms |
| TTI | < 3.8 sn | 3.8 – 7.3 sn | > 7.3 sn |
| SI | < 3.4 sn | 3.4 – 5.8 sn | > 5.8 sn |
Core Web Vitals: Resmi Üç Metrik
Google’ın 2020 yılında tanımladığı Core Web Vitals, sayfa deneyimini üç temel boyuttan ölçer: yükleme (LCP), görsel kararlılık (CLS) ve etkileşim hızı (INP). Bu üç metrik, Google Search Console’da raporlanan ve sıralama sinyali olarak kullanılan tek performans göstergeleridir.
LCP — Largest Contentful Paint (En Büyük İçerikli Boyama)
LCP, tarayıcının görünür alan içinde (viewport) oluşturduğu en büyük içerik öğesinin ekranda göründüğü anı ölçer. Başka bir ifadeyle kullanıcının sayfayı “yüklendi” olarak algıladığı an, büyük ölçüde LCP zamanlamasıyla örtüşür. Google’ın belirlediği eşiğe göre LCP 2,5 saniyenin altındaysa “İyi”, 2,5–4,0 saniye arasındaysa “Geliştirilmeli”, 4,0 saniyenin üzerindeyse “Kötü” olarak değerlendirilir.
LCP ölçümüne dahil olan element türleri şunlardır: <img> ve <image> elementleri, CSS background-image ile yüklenen görüntüler, <video> elementlerinin poster görselleri, satır içi metin içeren blok düzeyi elementler (paragraf, başlık vb.). İçerik yüklenirken en büyük element değişebilir; örneğin bir sayfa önce küçük bir resmi render edebilir, ardından daha büyük bir hero görselini; bu durumda LCP zamanlaması güncellenir ve son görüntülenen büyük elementin zamanı esas alınır.
LCP’yi kötüleştiren başlıca nedenler: yavaş sunucu yanıt süreleri (yüksek TTFB), render-blocking CSS ve JavaScript dosyaları, büyük ve optimize edilmemiş görseller, yavaş kaynak sunucuları ve önbellek eksikliğidir. LCP optimizasyonu hakkında ayrıntılı rehberimize başvurabilirsiniz.
CLS — Cumulative Layout Shift (Kümülatif Düzen Kayması)
CLS, sayfa yüklenirken veya kullanıcı sayfayla etkileşime girerken görünür içeriğin beklenmedik biçimde kayması durumunu ölçer. Bir düğmeye tıklamak üzereyken sayfanın kayması ve yanlış bir bağlantıya tıklamanız CLS’nin pratikteki yansımasıdır. Google’ın eşiği 0,1’dir; bu değerin altındaki CLS skoru “İyi”, 0,1–0,25 arası “Geliştirilmeli”, 0,25 üzeri “Kötü” sayılır.
CLS hesaplanırken şu formül kullanılır: impact fraction × distance fraction. Impact fraction, kaymadan etkilenen alanın viewport’a oranıdır; distance fraction ise kaymaya uğrayan elementin viewport içinde kat ettiği mesafenin viewport yüksekliğine oranıdır. Bu iki değerin çarpımı, tek bir düzen kayması için kaydedilen puanı verir; birden fazla kayma olduğunda bunların toplamı CLS skorunu oluşturur.
Layout shift’e yol açan yaygın kaynaklar şunlardır: boyutu önceden belirtilmemiş görseller ve videolar, geç yüklenen reklamlar veya iWidget’lar, üstten eklenen içerik (banner, bildirim), web fontlarının geç yüklenmesinden kaynaklanan metin kaymaları (FOIT/FOUT) ve JavaScript ile dinamik olarak eklenen öğeler. Her görsele ve video elementine width ve height özelliği eklemek, ya da CSS’de aspect-ratio kullanmak en temel önlemdir. CLS sorunlarınızı nasıl çözeceğinizi ayrıntılı olarak ele aldık.
INP — Interaction to Next Paint (Sonraki Boyamaya Etkileşim Süresi)
INP, bir kullanıcının sayfayla gerçekleştirdiği tüm etkileşimler (tıklama, dokunma, klavye girişi) sırasında geçen gecikmeyi ölçer ve bu sürelerin 98. yüzdeliğini tek bir INP skoru olarak raporlar. Google Mart 2024’te FID’in yerini INP’ye bırakmasıyla birlikte bu metrik, Core Web Vitals’ın etkileşim boyutunu temsil eden resmi gösterge hâline geldi. Eşik değerleri: 200 ms altı “İyi”, 200–500 ms arası “Geliştirilmeli”, 500 ms üzeri “Kötü”.
INP üç bileşenden oluşur: input delay (kullanıcının eylemi ile tarayıcının işlemi başlatması arasındaki süre), processing time (olay dinleyicilerinin ve JavaScript kodunun çalışma süresi) ve presentation delay (tarayıcının sonuçları ekranda görünür kılmak için gereken boyama ve kompozit süresi). INP’yi azaltmak için uzun JavaScript görevleri parçalanmalı, olay dinleyicileri optimize edilmeli ve ana iş parçacığı (main thread) mümkün olduğunca boşaltılmalıdır.
FID’den en önemli farkı şudur: FID yalnızca ilk etkileşimi ölçerken INP, sayfanın tüm yaşam döngüsü boyunca yapılan her etkileşimi değerlendirir. Bu sayede INP, form doldurma, menü açma, sekme değiştirme gibi sonraki etkileşimlerin yavaşlığını da yakalar. INP optimizasyonu için hazırladığımız rehberi incelemenizi öneririz.
Eski ve Kaldırılan Metrikler
Web performans standartları zaman içinde evrildi; bazı metrikler daha iyi alternatifler geliştirildiğinde kullanımdan kaldırıldı. Bu tarihsel bilgi, eski raporları yorumlamak ve araç çıktılarını anlamak için hâlâ değerlidir.
FID — First Input Delay (İlk Giriş Gecikmesi)
FID, kullanıcının sayfayla ilk kez etkileşime girdiği an (ilk tıklama, dokunma veya tuş basımı) ile tarayıcının bu etkileşimi işlemeye başlaması arasındaki süreyi ölçüyordu. Eşiği 100 ms altı “İyi”, 100–300 ms “Geliştirilmeli”, 300 ms üzeri “Kötü” idi. FID, yalnızca ilk etkileşimi ölçmesi ve sayfa etkileşiminin tamamını kapsamadığı için yetersiz kalmaktaydı; bir kullanıcının ilk tıklaması hızlı görünse bile sonraki tıklamalar yavaş kalabiliyordu.
Google, Mart 2024 itibarıyla FID’i resmi Core Web Vitals setinden çıkararak yerine INP’yi koydu. Bunun temel nedeni, INP’nin sayfanın tüm etkileşim yaşam döngüsünü temsil etmesi ve gerçek kullanıcı deneyimiyle çok daha güçlü korelasyon göstermesidir. Eski Search Console raporlarında ya da 2024 öncesi performans kaydı içeren CrUX verilerinde FID değerlerine rastlayabilirsiniz; bu veriler geçerlidir ancak artık sıralama sinyali işlevi görmemektedir.
FMP — First Meaningful Paint (İlk Anlamlı Boyama)
FMP, sayfanın birincil içeriğinin ekranda göründüğü zamanı yakalamayı amaçlıyordu. Kavramsal olarak doğru olmakla birlikte, “anlamlı” içeriğin tanımı sayfa türüne göre çok fazla değiştiğinden algoritmanın hesaplama güvenilirliği yetersiz kaldı; iki farklı tarayıcı çalıştırması aynı sayfada farklı FMP değerleri üretebiliyordu. Google, LCP’nin daha tutarlı ve yorumlanabilir bir alternatif sunduğunu belirterek FMP’yi Lighthouse’dan kaldırdı.
FMP teknik olarak “layout significance” değişimine dayanan bir algoritmaya sahipti; sayfa render edilirken layout’un en büyük görsel sıçramayı yaptığı an FMP olarak işaretleniyordu. Bu metodun kırılganlığı nedeniyle aynı sayfanın farklı ağ koşullarında ya da farklı cihazlarda tutarsız FMP değerleri vermesi sık görülen bir sorundu.
SI — Speed Index (Hız Endeksi)
Speed Index, sayfanın görsel olarak ne kadar hızlı dolduğunu sayısal bir değerle ifade eder. Sayfa yüklenmesi sırasında alınan ekran görüntülerinin görsel tamamlanma yüzdeleri analiz edilerek hesaplanır; düşük değer daha hızlı görsel dolum anlamına gelir. SI eşiği: 3,4 saniye altı “İyi”, 3,4–5,8 saniye “Geliştirilmeli”, 5,8 saniye üzeri “Kötü” kabul edilir.
SI hâlâ Lighthouse audit çıktısında yer almakta ve Lighthouse Performance skorunun hesaplanmasına katkıda bulunmaktadır. LCP gibi belirli bir elementi değil, sayfanın genel görsel ilerleme hızını ölçtüğünden özellikle büyük, karmaşık sayfa düzenlerinin karşılaştırmalı değerlendirmesinde kullanışlıdır. WebPageTest filmstrip görünümüyle birlikte yorumlandığında SI, hangi yükleme aşamasında görsel gecikmenin yaşandığını tespite yardımcı olur.
Yükleme ve Algılanan Hız Metrikleri
Bu gruptaki metrikler sayfanın ne kadar hızlı yüklendiğini ve kullanıcının ne zaman “hazır” hissettiğini farklı açılardan ölçer. Hepsi birbiriyle ilişkilidir ve biri iyileştiğinde diğerleri de genellikle olumlu yönde etkilenir.
TTFB — Time to First Byte (İlk Bayta Kadar Geçen Süre)
TTFB, tarayıcının sunucuya HTTP isteği gönderdiği andan sunucunun yanıtının ilk baytını aldığı ana kadar geçen toplam süredir. Sunucu işleme süresi, ağ gecikmesi ve DNS çözümleme süresi TTFB’ye dahildir. Google’ın güncel eşiğine göre 800 ms altı “İyi”, 800 ms–1,8 saniye “Geliştirilmeli”, 1,8 saniye üzeri “Kötü” olarak değerlendirilir.
Yüksek TTFB en yaygın olarak yavaş sunucu konfigürasyonu, veritabanı sorgu süresi, sunucu taraflı render (SSR) gecikmeleri veya coğrafi uzaklık nedeniyle oluşur. CDN kullanımı, edge caching ve veritabanı optimizasyonu ile TTFB dramatik biçimde düşürülebilir. TTFB aynı zamanda LCP için bir tavan oluşturur; sunucu yanıtı yavaşsa LCP’nin iyi olması mümkün değildir çünkü tüm içerik yüklemesi TTFB’nin bitişiyle başlar.
FCP — First Contentful Paint (İlk İçerikli Boyama)
FCP, tarayıcının herhangi bir metin, görsel, SVG veya canvas içeriğini ekranda ilk kez oluşturduğu andır. Boş beyaz ekranın son bulduğu anı temsil ettiği için kullanıcının sayfanın “bir şeyler yapıyor” olduğunu ilk fark ettiği andır. Eşiği 1,8 saniye altı “İyi”, 1,8–3,0 saniye “Geliştirilmeli”, 3,0 saniye üzeri “Kötü” olarak belirlenmiştir.
FCP ile LCP arasındaki kritik fark şudur: FCP sayfada ilk içeriğin göründüğü anı, LCP ise en büyük içeriğin göründüğü anı ölçer. FCP her zaman LCP’den önce ya da eş zamanlı gerçekleşir. Bir sayfanın FCP’si hızlı olsa bile LCP yavaş olabilir; bu durum, sayfanın başlangıçta küçük metin parçaları gösterip ana görsel içeriği geç yüklemesinden kaynaklanır. Render-blocking CSS’i azaltmak ve sunucu yanıt süresini iyileştirmek her iki metriği de olumlu yönde etkiler.
TTI — Time to Interactive (Etkileşime Hazır Olma Süresi)
TTI, sayfanın görsel olarak yüklenmiş ve JavaScript kodunun kayıtlı olay dinleyicilerinin kullanıcı etkileşimlerine güvenilir biçimde yanıt verebilir hâle geldiği anı ifade eder. Teknik olarak TTI, son uzun görevden (Long Task) sonra main thread’in en az 5 saniye boyunca boşta kaldığı ilk noktanın geriye sayılmasıyla tespit edilir. Eşiği 3,8 saniye altı “İyi”, 3,8–7,3 saniye “Geliştirilmeli”, 7,3 saniye üzeri “Kötü”dür.
TTI ile FCP arasındaki boşluk, sayfanın “göründüğü” ama henüz “kullanılabilir” olmadığı döngüyü ortaya koyar. Bu boşluğun uzaması, kullanıcının sayfa yüklendi zannederek tıkladığı hâlde hiçbir tepki alamaması anlamına gelir; bu da hayal kırıklığı ve hemen çıkma (bounce) riski yaratır. Büyük JavaScript paketlerini parçalamak (code splitting) ve kritik olmayan kodları ertelemek (defer) TTI’yi iyileştirmenin en etkili yollarıdır.
TBT — Total Blocking Time (Toplam Engelleme Süresi)
TBT, FCP ile TTI arasındaki süre içinde main thread’i 50 ms’yi aşan uzun görevlerin her birinin toplam engelleme süresinin toplamıdır. Örneğin 80 ms süren bir JavaScript görevi, 50 ms eşiğin 30 ms üzerinde kaldığından TBT’ye 30 ms katkı yapar. Eşiği 200 ms altı “İyi”, 200–600 ms “Geliştirilmeli”, 600 ms üzeri “Kötü”dür.
TBT, INP ile güçlü korelasyon gösteren bir lab metriğidir. Gerçek kullanıcı etkileşim verisine (field data) dayanan INP’nin aksine TBT, Lighthouse gibi lab ortamında ölçülebilir ve CI/CD süreçlerine entegre edilebilir. Yüksek TBT, büyük JavaScript paketleri, üçüncü taraf scriptler veya ağır render mantığının main thread’i bloke ettiğini gösterir.
DCL — DOMContentLoaded
DOMContentLoaded olayı, tarayıcının HTML belgesini tamamen parse ettiği ve DOM ağacını oluşturduğu anda tetiklenir; ancak görseller, iFrame’ler ve stil sayfaları gibi harici kaynakların yüklenmesini beklemez. Geliştirici araçlarında Network sekmesinde mavi dikey çizgi olarak görünür. DCL zamanlaması, JavaScript’in DOM’a erişebildiği en erken anı ifade ettiğinden DOMContentLoaded olayına bağlı scriptler bu andan sonra güvenle çalışır.
DCL, FCP ile TTI arasında bir yerde konumlanır; FCP’den önce ya da sonra gerçekleşebilir, bu durum sayfanın render stratejisine bağlıdır. Parser-blocking scriptler DCL’yi geciktirirken defer özelliğiyle yüklenen scriptler DCL’yi bekler ama onu engellemez. DCL’nin uzaması genellikle parse-blocking inline script veya senkron external script yüklenmesinin işaretidir.
Onload Olayı
window.onload (ya da load) olayı, sayfadaki tüm kaynaklar (görseller, stil sayfaları, iFrame’ler dahil) tamamen yüklendiğinde tetiklenir. DevTools’ta kırmızı dikey çizgiyle gösterilir ve genellikle DCL’den daha geç gerçekleşir. Onload’u kesinlikle bir performans metriği olarak kullanmamak gerekir; çünkü sayfa zaten kullanılabilir hâldeyken yüklenmekte olan offscreen görseller bu olayı geciktirir.
Onload ile DCL arasındaki fark sayfanın ağır kaynak yüküyle doğru orantılıdır. Çok sayıda büyük görsel, embed video veya üçüncü taraf widget’ı olan sayfalarda onload çok daha geç gelir. Performans optimizasyonu açısından önemli olan, kullanıcı deneyimini doğrudan etkileyen FCP, LCP ve TTI’dir; onload bu zincirlemenin son halkasıdır.
Render ve İşleme Terimleri
Bu terimler, tarayıcının HTML’den ekrandaki piksellere nasıl ulaştığını ve bu süreçte nelerin performansı etkilediğini açıklar. Teknik SEO hizmetlerimiz kapsamında render optimizasyonu sıklıkla ele aldığımız bir konudur.
Critical Rendering Path (Kritik Render Yolu)
Critical Rendering Path, tarayıcının bir HTML belgesini alıp ekranda görsel içerik oluşturuncaya kadar gerçekleştirdiği adımlar dizisidir. Bu adımlar sırayla şöyledir: HTML parse edilerek DOM (Document Object Model) oluşturulur; CSS parse edilerek CSSOM (CSS Object Model) oluşturulur; DOM ve CSSOM birleştirilerek Render Tree elde edilir; her elementin konumu ve boyutu hesaplandığı Layout (Reflow) aşaması gerçekleşir; pikseller belleğe çizildiği Paint aşaması tamamlanır ve son olarak GPU katmanları birleştirilerek ekranda gösterildiği Composite aşaması gerçekleşir.
Bu yolun herhangi bir noktasındaki gecikme veya engelleme FCP ve LCP değerlerini doğrudan etkiler. Kritik render yolunu kısaltmak, CSS ve JS gibi render-blocking kaynakları optimize etmek ve DOM boyutunu küçük tutmak temel performans stratejilerinin başında gelir. Render tree oluşturulmadan önce hem DOM hem de CSSOM tam olarak hazır olmalıdır; bu nedenle CSS, render’ı JavaScript’ten çok daha doğrudan bloke edebilir.
Render-Blocking Resources (Render’ı Engelleyen Kaynaklar)
Render-blocking resources, tarayıcının DOM parse etmeyi ya da sayfayı boyamayı durdurup önce yüklenmesini beklediği CSS ve JavaScript dosyalarıdır. <head> içine yerleştirilen harici CSS dosyaları CSSOM tamamlanana kadar render’ı durdurur; senkron <script> etiketleri ise hem parser’ı hem de render’ı bloke eder. Bu kaynakların varlığı, sayfa içeriği hazır olsa bile kullanıcının boş ekrana bakması anlamına gelir.
CSS’in render-blocking etkisini azaltmanın yolları arasında critical CSS inline etmek, kullanılmayan CSS’i kaldırmak ve media özelliğiyle koşullu yükleme yapmak sayılabilir. JavaScript için async veya defer özelliklerini kullanmak, ya da scriptleri </body> etiketinden önce yerleştirmek standart yaklaşımlardır. Lighthouse “Eliminate render-blocking resources” denetimi, sayfanızdaki hangi kaynakların bu kategoriye girdiğini ve kazanılabilecek süreyi gösterir.
Parser-Blocking Scripts (Parser’ı Engelleyen Scriptler)
Bir <script> etiketi async veya defer özelliği olmadan sayfaya eklendiğinde tarayıcı HTML parse etmeyi durdurup scriptin indirilmesini ve çalışmasını bekler; buna parser-blocking (ya da parser-blocking) script denir. Bu durum hem DCL hem de FCP’yi geciktirir.
async özelliği, scriptin arka planda eş zamanlı indirileceği ve hazır olduğu an parse’ı keserek çalışacağı anlamına gelir; sıralamayı garanti etmez. defer ise scriptin parse tamamlandıktan sonra, DOM hazır olduğunda ve DCL’den önce sıralı biçimde çalışmasını sağlar. Genel kural: sıra bağımsız analitik ve reklam scriptleri için async, sıra önemli uygulama scriptleri için defer kullanın.
Long Tasks (Uzun Görevler)
Main thread üzerinde 50 ms’den uzun süren herhangi bir JavaScript görevi “Long Task” olarak tanımlanır. Bir Long Task çalışırken tarayıcı kullanıcı etkileşimlerine, animasyonlara veya başka herhangi bir işleme yanıt veremez; bu süre boyunca sayfa donmuş gibi davranır. 50 ms eşiği, insan algısının “anlık” geri bildirim olarak hissedebileceği üst sınırdan (100 ms) geriye doğru hesaplanarak belirlenmiştir.
Long Tasks’ı tespit etmek için Chrome DevTools Performance panelinde kırmızı üçgen köşeli, uzun bloklar olarak görüntülenir. PerformanceObserver API’siyle de programatik olarak izlenebilir. TBT, Long Task’ların 50 ms eşiğini aşan kısımlarının toplamı olduğundan bu iki kavram doğrudan ilişkilidir; Long Task’ları parçalamak (task splitting) TBT’yi ve dolayısıyla INP’yi iyileştirir.
Main Thread (Ana İş Parçacığı)
Ana iş parçacığı, tarayıcının JavaScript çalıştırdığı, DOM ve CSSOM’u parse ettiği, Layout ve Paint adımlarını gerçekleştirdiği tek iş parçacığıdır. JavaScript tek iş parçacıklı çalışır; yani aynı anda yalnızca bir görev işlenebilir. Bu kısıt, bir JavaScript görevinin main thread’i meşgul ettiği süre boyunca tarayıcının başka hiçbir şey yapamamasına yol açar.
Main thread’i hafifletmenin başlıca yolları şunlardır: hesaplama ağırlıklı görevleri Web Workers’a taşımak, uzun görevleri küçük parçalara bölerek aralarında yield noktaları oluşturmak (setTimeout(0) veya scheduler.yield()), üçüncü taraf scriptleri asenkron yüklemek ve gereksiz JavaScript’i bundle’dan çıkarmak. Ana iş parçacığının uygun kalması, INP ve TBT metriklerinin iyi aralıkta kalmasının temel koşuludur.
Layout Thrashing (Düzen Çırpınması)
Layout Thrashing, JavaScript kodunun bir döngü içinde DOM okuma ve yazma işlemlerini sırayla gerçekleştirmesi sonucu tarayıcının layout hesaplamasını defalarca zorunlu kılmasıdır. Bir elementin offsetWidth değerini okuyup ardından başka bir elementin width değerini yazarsanız tarayıcı, güncellenen değerlerin doğru okunması için layout’u yeniden hesaplamak zorunda kalır; bu süreç döngüde tekrarlanırsa ciddi performans kayıplarına yol açar.
Layout Thrashing’i önlemek için okuma ve yazma işlemlerini gruplayan requestAnimationFrame kullanılmalı ya da FastDOM gibi kütüphanelerden yararlanılmalıdır. Modern framework’lerin (React, Vue) sanal DOM yaklaşımı, bu sorunu büyük ölçüde otomatik olarak azaltır. Ancak doğrudan DOM manipülasyonu içeren eski kodlarda layout thrashing hâlâ sık görülen bir performans tuzağıdır.
Paint ve Composite (Boyama ve Birleştirme)
Paint, tarayıcının Layout aşamasında hesaplanan piksel bilgisini belleğe yazma sürecidir; metin rengi, arka plan, gölge ve kenarlıkların çizilmesi bu aşamada gerçekleşir. Composite ise farklı GPU katmanlarını (layer) birleştirerek son görsel çıktıyı ekrana taşıma aşamasıdır. CSS will-change: transform veya transform: translateZ(0) kullanıldığında tarayıcı, o elementi ayrı bir GPU katmanına taşır; bu sayede söz konusu elementin animasyonu Layout ve Paint adımlarını tetiklemeden, yalnızca Composite aşamasında GPU üzerinde gerçekleşir.
Sık paint tetikleyen CSS özellikleri (arka plan rengi, box-shadow, kenarlık) dikkatli kullanılmalıdır. Animasyonlar için transform ve opacity tercih edilmelidir; bu iki özellik Paint’i atlar ve yalnızca Composite’te işlenir, dolayısıyla animasyon sürekliliği (jank-free) açısından en uygun seçeneklerdir.
Reflow ve Repaint (Yeniden Düzenleme ve Yeniden Boyama)
Reflow (layout recalculation), DOM’da bir elementin boyutu, konumu veya içeriği değiştiğinde tarayıcının tüm etkilenen elementlerin geometrisini yeniden hesapladığı süreçtir. Reflow pahalıdır çünkü değişen elementin atalarını, kardeşlerini ve torunlarını da etkileyebilir; DOM büyüdükçe maliyet artar. Repaint ise elementin görsel görünümü (renk, şeffaflık vb.) değiştiğinde layout hesaplaması gerekmeden yalnızca piksellerin yeniden çizildiği daha ucuz bir işlemdir.
Maliyeti açısından sıralama şöyledir: Composite < Repaint < Reflow. Performans için öncelikle yalnızca composite gerektiren CSS değişikliklerini tercih etmek gerekir. Elementin display: none ve ardından display: block yapılması hem Reflow hem Repaint tetikler; visibility: hidden ise Repaint tetikler ama Reflow’a neden olmaz. Bu farkları anlamak, smooth animasyon ve düşük INP için kritiktir.
Optimizasyon Teknikleri Terimleri
Bu bölüm, Core Web Vitals skorlarını iyileştirmek için uygulanan teknik yöntemleri ve bunların arkasındaki kavramları ele alır.
Resource Hints: preload, preconnect, prefetch, dns-prefetch
<link rel="preload">: Mevcut sayfada kesinlikle ihtiyaç duyulacak kritik bir kaynağın (LCP görseli, kritik font, öncelikli CSS) tarayıcı tarafından erken indirilmesini sağlar. “Bu kaynağa ihtiyacın var ve şimdi başla” mesajıdır; yanlış kullanımı ise bant genişliği israfına yol açar.
<link rel="preconnect">: Yakın gelecekte istek yapılacak bir origin’e karşı DNS çözümleme, TCP el sıkışması ve TLS müzakeresini önceden tamamlar. CDN, Google Fonts veya API sunucuları için idealdir; gereksiz kullanımı boşta bağlantı açar.
<link rel="prefetch">: Bir sonraki sayfada muhtemelen gerekli olacak kaynakları düşük öncelikle arka planda indirir. Kullanıcı o sayfaya geçtiğinde kaynak cache’den gelir. Preload ile karıştırılmamalıdır; prefetch mevcut sayfa için değil, gelecek navigasyon için çalışır.
<link rel="dns-prefetch">: Yalnızca DNS çözümlemesini önceden yaparak sonraki isteklerde DNS gecikmesini ortadan kaldırır. Preconnect’ten ucuzdur ama TCP/TLS adımlarını tamamlamaz; düşük bağlantı maliyetiyle çok sayıda harici origin için kullanılabilir.
fetchpriority — Kaynak Önceliği
fetchpriority özelliği (high, low, auto), tarayıcıya belirli bir kaynağın ne kadar öncelikli indirilmesi gerektiğini söyleyen HTML özelliğidir. LCP görseliniz için <img fetchpriority="high"> kullanmak, tarayıcının bant genişliğini bu görsele öncelik vermesini sağlar ve LCP süresini önemli ölçüde iyileştirebilir. Eklenen küçük bir özelliğin LCP’ye katkısı özellikle mobil ağlarda dramatik olabilmektedir.
fetchpriority="low" ise offscreen görseller veya geç yüklenen içerikler için kullanılır; bu sayede kritik kaynaklar daha fazla ağ kapasitesi alır. Lighthouse “Preload Largest Contentful Paint image” önerisini gördüğünüzde çoğunlukla fetchpriority="high" veya preload kombinasyonu bu sorunu çözer.
Lazy Loading (Tembel Yükleme)
Lazy loading, sayfa yüklendiğinde görünür alanda olmayan görsellerin ve iFrame’lerin hemen indirilmemesi; kullanıcı o içeriğe kaydırdığında yüklenmesi tekniğidir. HTML’de <img loading="lazy"> özelliğiyle yerel tarayıcı desteğiyle kolayca uygulanır; JavaScript kütüphanesi gerekmez. Bu sayede ilk yükleme sırasında ağ bant genişliği yalnızca görüntülenen içeriğe ayrılır.
LCP görselinize loading="lazy" eklemeyin; bu durum LCP değerini ciddi biçimde kötüleştirir çünkü tarayıcı bu görseli viewport’a kaydırılana kadar indirmez. Lazy loading yalnızca fold altındaki (ekranın görünür alanı dışındaki) içerikler için kullanılmalıdır. JavaScript tabanlı Intersection Observer API, tarayıcı desteğinin yetersiz olduğu eski projelerde ya da daha özelleştirilmiş kontrol gereken durumlarda alternativ olarak tercih edilir.
Code Splitting (Kod Bölme)
Code splitting, büyük JavaScript bundle’ını daha küçük parçalara ayırarak yalnızca o an ihtiyaç duyulan kodu indirme tekniğidir. Modern JavaScript bundler’ları (Webpack, Vite, Rollup) import() dynamic syntax’ını kullanarak route bazlı veya bileşen bazlı kod bölmeyi otomatik yapabilir. Bu sayede kullanıcı yalnızca geçerli sayfanın JS’ini indirir; diğer sayfaların kodu arka planda veya ihtiyaç anında yüklenir.
Route-based splitting, SPA (Single Page Application) mimarilerinde en yaygın yaklaşımdır; her route ayrı bir chunk’a dönüştürülür. Component-level splitting ise modal, tab içeriği veya ağır grafik bileşenleri gibi koşullu render edilen büyük bileşenler için kullanılır. Code splitting, TTI ve TBT metriklerini doğrudan iyileştirir çünkü main thread’e yüklenen JavaScript miktarını azaltır.
Tree Shaking (Ağaç Sallama)
Tree shaking, uygulamanın gerçekte kullanmadığı JavaScript kodunu derleme aşamasında tespit ederek son bundle’a dahil etmeme tekniğidir. ES module (import/export) sözdizimi kullanan kodlarda bundler, statik analiz yaparak hangi dışa aktarımların hiç kullanılmadığını belirleyebilir. Örneğin lodash gibi büyük bir kütüphanenin yalnızca iki fonksiyonunu kullandığınızda tree shaking, geri kalan binlerce satır kodun bundle’a girmesini önler.
Tree shaking’in çalışması için CommonJS (require) yerine ESM sözdizimi kullanılmalı ve kütüphanelerin side-effect içerip içermediği package.json’daki sideEffects alanıyla belirtilmelidir. Bundle analiz araçları (webpack-bundle-analyzer, Rollup Visualizer) hangi modüllerin en fazla yer kapladığını görselleştirir ve tree shaking optimizasyonuna yön verir.
Critical CSS (Kritik Stil)
Critical CSS, kullanıcı sayfayı ilk açtığında görünen alanı (above the fold) doğru biçimde render etmek için gereken minimum CSS kurallarının HTML’in <head> bölümüne inline olarak eklenmesi tekniğidir. Bu yaklaşımla tarayıcı, harici CSS dosyasının indirilmesini beklemek zorunda kalmaz ve render daha erken başlar; FCP ve LCP değerleri iyileşir. Critters, Critical gibi araçlar bu süreci otomatize edebilir.
Tüm CSS’i inline etmek doğru değildir; yalnızca viewport’ta görünen içerikle ilgili kurallar inline edilmeli, geri kalan CSS ise <link rel="stylesheet" media="print" onload="this.media='all'"> gibi bir teknikle asenkron yüklenmelidir. Critical CSS’in boyutu tarayıcı cache’ini atlattığından her sayfa yüklemesinde gönderildiğini unutmayın; bu nedenle mümkün olduğunca küçük tutulmalıdır.
Font Display (Yazı Tipi Gösterim Stratejisi)
font-display CSS özelliği, web fontlarının yüklenirken metnin nasıl davranacağını belirler. Beş değer vardır: block — metin görünmez, font yüklenince gösterilir (FOIT — Flash of Invisible Text); swap — sistem fontu hemen gösterilir, web fontu yüklenince swap edilir (FOUT — Flash of Unstyled Text); fallback — kısa süre gizleme, ardından sistem fontu, font geç gelirse swap yok; optional — bağlantı hızına göre font yüklenebilir ya da atlanır; auto — tarayıcı varsayılanı.
CLS açısından swap değeri dikkatli kullanılmalıdır; fallback font ile web fontunun farklı metrikleri (x-height, character width) layout kaymasına yol açabilir. Bunu önlemek için CSS size-adjust, ascent-override ve descent-override özellikleriyle fallback fontu web fontuna yaklaştırmak mümkündür. Google Fonts, display=swap parametresini URL’ye eklediğinizde bu değeri otomatik uygular.
Görsel Formatlar: WebP, AVIF, JPEG XL
WebP: Google tarafından geliştirilen ve JPEG’e göre ortalama %25–35 daha küçük dosya boyutu sunan görsel formatıdır. Tüm modern tarayıcılarda desteklenmektedir. Hem kayıplı hem de kayıpsız sıkıştırmayı ve şeffaflığı (alpha channel) destekler.
AVIF: AV1 video codec’ine dayanan ve WebP’ye göre ortalama %50 daha iyi sıkıştırma sağlayan modern formattır. Renk derinliği ve HDR desteği açısından da üstündür. Tarayıcı desteği hızla yaygınlaşmaktadır ancak kodlama süresi uzundur; CDN düzeyinde dönüştürme veya build-time araçlar gerektirir.
JPEG XL: ISO standardı olan yeni nesil format; hem yeni görüntüler için yüksek verimli sıkıştırma hem de mevcut JPEG dosyalarının kayıpsız yeniden kodlanmasını sunar. Tarayıcı desteği hâlâ kısıtlıdır; Chrome desteği 2024’te eklendi. Uzun vadede AVIF ile birlikte web’in standart görsel formatı olmaya adaydır.
Responsive Images (Duyarlı Görseller)
srcset özelliği, farklı çözünürlükler için birden fazla görsel dosyasının tarayıcıya sunulmasını sağlar; tarayıcı cihaz piksel yoğunluğuna ve viewport genişliğine göre en uygun boyutu seçer. sizes özelliği ise tarayıcıya görselin sayfada görüneceği genişliği bildirir ve bu bilgiyle doğru kaynak seçilir. <picture> elementi ise farklı formatları (AVIF, WebP, JPEG) sıralı sunarak en iyi tarayıcı desteğini garanti eder.
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img
src="hero.jpg"
srcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"
sizes="(max-width: 600px) 480px, (max-width: 1024px) 800px, 1200px"
width="1200"
height="600"
fetchpriority="high"
alt="Hero görseli"
>
</picture>
Doğru görsel boyutunu gönderememek, kullanıcının gereksiz yere büyük dosya indirmesine yol açar ve LCP’yi olumsuz etkiler. Lighthouse “Properly size images” denetimi bu fırsatları tespit eder.
CDN — Content Delivery Network (İçerik Dağıtım Ağı)
CDN, statik içerikleri (görseller, CSS, JS, font) dünya genelindeki edge node’larda (uç sunucu) önbelleğe alarak kullanıcıya en yakın konumdan sunmayı sağlayan dağıtık sunucu ağıdır. Bu sayede ağ gecikmesi (latency) azalır, TTFB düşer ve kaynak sunucu üzerindeki yük hafifler. İstanbul’daki bir kullanıcı için Türkiye’deki ya da Avrupa’daki bir edge node, ABD’deki kaynak sunucudan çok daha hızlı yanıt verir.
CDN’in temel kavramları şunlardır: Edge Node — kullanıcıya yakın önbellekleme noktası; TTL (Time to Live) — içeriğin önbellekte ne kadar süre tutulacağı; Cache-Control header — tarayıcı ve CDN önbellekleme davranışını yöneten HTTP başlığı; Purge — içerik güncellendiğinde önbelleği temizleme işlemi. Cloudflare, Fastly, AWS CloudFront ve Vercel Edge Network, yaygın kullanılan CDN sağlayıcılarıdır.
HTTP/2 ve HTTP/3
HTTP/2, tek bir TCP bağlantısı üzerinden birden fazla isteği eş zamanlı gönderip alabilme (multiplexing) özelliğiyle HTTP/1.1’deki head-of-line blocking sorununu çözüyor. Header sıkıştırma (HPACK), server push ve ikili (binary) protokol gibi özelliklerle her istek için ayrı bağlantı açma ihtiyacını ortadan kaldırır; bu sayede bağlantı kurma maliyeti düşer ve özellikle çok sayıda küçük kaynağın yüklendiği sayfalarda ciddi hız kazanımı sağlar.
HTTP/3, UDP tabanlı QUIC protokolü üzerine inşa edilmiştir. TCP’nin aksine QUIC, paket kaybını bağlantı düzeyinde değil akış düzeyinde ele alır; bu sayede bir paketin kaybolması yalnızca o akışı etkiler, diğer akışları durdurmaz (true multiplexing). Ayrıca 0-RTT bağlantı kurma özelliğiyle tekrarlayan bağlantılarda el sıkışma gecikmesini neredeyse sıfıra indirir. Her iki protokolün SEO’ya doğrudan etkisi olmamakla birlikte, TTFB ve kaynak yükleme sürelerini iyileştirerek Core Web Vitals’a dolaylı katkı sağlar.
Brotli ve Gzip Sıkıştırma
Gzip, 1990’lardan bu yana web sunucularda yaygın olarak kullanılan sıkıştırma algoritmasıdır; HTML, CSS ve JavaScript gibi metin tabanlı kaynakları ortalama %60–70 oranında küçültür. Brotli ise Google tarafından geliştirilen daha yeni bir algoritmadır; aynı kaynakları Gzip’e göre ortalama %15–25 daha iyi sıkıştırır ve modern tarayıcıların tamamında desteklenmektedir.
Çoğu web sunucusu (Nginx, Apache) ve CDN hizmeti her iki algoritmayı da destekler; tarayıcı Accept-Encoding: br, gzip başlığıyla hangisini desteklediğini bildirir, sunucu ise uygun olanı gönderir. JavaScript bundle’larında Brotli kullanmak TTFB ve kaynak yükleme sürelerini küçük ama ölçülebilir biçimde iyileştirebilir. Statik Brotli sıkıştırma (pre-compressed), sunucu CPU’su yerine derleme aşamasında sıkıştırma yapıldığından ek gecikme yaratmaz.
Service Worker ve Önbellekleme
Service Worker, tarayıcı ile ağ arasında proxy gibi davranan, arka planda çalışan bir JavaScript dosyasıdır. Ağ isteklerini durdurabilir, önbellekten yanıt döndürebilir ve çevrimdışı çalışma sağlayabilir. Stale-while-revalidate stratejisi özellikle değerlidir: önbellekteki eski içerik anında kullanıcıya sunulurken arka planda yeni içerik indirilir; böylece hem hız hem de güncellik bir arada elde edilir.
Service Worker önbelleklemesi, CDN önbelleklemesinin ötesinde son kullanıcının cihazındaki önbelleği kontrol eder ve tekrarlayan ziyaretlerde inanılmaz hız artışı sağlar. Özellikle Progressive Web App (PWA) mimarilerinin temel bileşenidir. Workbox kütüphanesi, Service Worker stratejilerini kolayca uygulamak için Google tarafından desteklenen açık kaynaklı çözümdür.
Above the Fold (Ekran Üstü Alan)
“Above the fold”, kullanıcı sayfaya ilk geldiğinde herhangi bir kaydırma yapmadan görebildiği ekran alanıdır. Bu terimin önemi şuradan gelir: tarayıcı yükleme sırasında önce bu alana düşen içeriği render eder; Lighthouse ve diğer araçlar da bu alana yönelik optimizasyonları (critical CSS, preload, görsel boyutu) öncelikli olarak değerlendirir. LCP genellikle above-the-fold alanındaki en büyük elementin boyamasıyla örtüştüğünden bu alan doğrudan bir Core Web Vitals sinyalidir.
Ekran üstü alanını iyileştirmenin somut adımları: Hero görselini fetchpriority="high" ile preload etmek, bu alanın CSS’ini inline etmek, font yüklemesini preconnect ve font-display: optional ile optimize etmek. Viewport boyutu cihaza göre değiştiğinden above-the-fold içerik de değişebilir; mobil ve masaüstü ayrı ayrı değerlendirilmelidir.
Ölçüm ve Veri Terimleri
Performans iyileştirmelerinin gerçekten işe yarayıp yaramadığını anlamak için doğru veri kaynaklarını ve ölçüm metodolojisini bilmek gerekir.
Lab Data ve Field Data (Laboratuvar ve Saha Verisi)
Lab data, kontrol altındaki bir ortamda (sabit cihaz, sabit ağ, sabit tarayıcı) yapılan ölçümdür; Lighthouse’un ürettiği veriler bu kategoriye girer. Tekrarlanabilir, hata ayıklaması kolay ve CI/CD süreçlerine entegre edilebilir; ancak gerçek kullanıcı koşullarını yansıtmaz.
Field data, gerçek kullanıcıların farklı cihazlarında, ağlarında ve konumlarında elde edilen gerçek deneyim ölçümüdür; CrUX ve özel RUM araçları bu veriye dayanır. Gerçek dünyayı temsil eder ama hata ayıklaması güçtür ve yeterli trafik olmadan istatistiksel anlam taşımaz. Google, sıralama sinyali için field data’yı (CrUX) kullanır; lab data ancak CrUX verisi olmayan URL’ler için yedek olarak devreye girer.
CrUX — Chrome User Experience Report
CrUX, Chrome tarayıcısının gerçek kullanıcılardan opt-in bazında topladığı performans metrik veri setidir. URL düzeyinde ve origin düzeyinde raporlama sunar; son 28 günlük kayan pencereyi kapsar. Yalnızca yeterli sayıda Chrome kullanıcısı ziyaret eden URL’ler için veri mevcuttur; az trafikli sayfalar CrUX’ta görünmeyebilir.
CrUX verisi Google Search Console (Core Web Vitals raporu), PageSpeed Insights ve CrUX API aracılığıyla erişilebilir. Veri koleksiyonu için kullanıcıların “Chrome Kullanım İstatistiklerini Paylaş” seçeneğini aktif etmiş olması ve gizli (incognito) modda gezmiyor olması gerekir. Eğitim materyallerindeki “gerçek kullanıcı verisi” ifadesi büyük ölçüde CrUX’a işaret eder.
p75 — 75. Yüzdelik Dilim
Google, Core Web Vitals değerlendirmesinde metrik değerlerinin 75. yüzdelik dilimini (p75) kullanır. Yani 100 kullanıcının ziyaretini sıralarsanız, 75. en yavaş kullanıcının deneyimi sıralama sinyali olarak değerlendirilen değeri belirler. Bu yaklaşım, en yavaş kullanıcıları (p95, p99) değil ama medyanı (p50) da aşan bir noktayı hedef alarak geniş çaplı gerçek dünya etkisini dengelemeyi amaçlar.
p50 (medyan) performansı iyi görünen bir site, p75’te “Geliştirilmeli” ya da “Kötü” kategorisine düşebilir; bu durum, kullanıcıların önemli bir bölümünün kötü deneyim yaşadığını gösterir. Optimizasyon çalışmalarını yönlendirirken özellikle yavaş cihaz ve bağlantı kullanan segment olan p75–p95 kullanıcılarına yönelik iyileştirmelere odaklanmak etkili bir stratejidir.
İyi / Geliştirilmeli / Kötü Eşik Değerleri
Google, her Core Web Vitals metriği için üç renk kodu belirlemiştir: yeşil (İyi), turuncu (Geliştirilmeli), kırmızı (Kötü). Bu sınıflandırma, p75 değerinin hangi aralığa düştüğüne göre yapılır. Sayfanın “İyi” sınıflandırması alması için tüm Core Web Vitals metriklerinin p75 değerinin “İyi” eşiğini geçmesi gerekir; tek bir metriğin kötü olması sayfanın genel değerlendirmesini düşürür.
Bu sınıflandırma, Google Search Console’daki “Core Web Vitals” raporunda URL grupları düzeyinde görselleştirilir. Lighthouse’da ise her audit için ayrı renk kodlaması yapılır ancak bunlar field data değil lab data değerlerine dayanır; dolayısıyla Search Console’daki rapordan farklılık gösterebilir.
Lighthouse
Lighthouse, Google tarafından geliştirilen ve Chrome’a entegre bir açık kaynak performans analiz aracıdır. Performance, Accessibility, Best Practices ve SEO olmak üzere dört kategoride 0–100 arası puan üretir. Performance skoru; LCP, TBT, FCP, CLS ve Speed Index metriklerine ağırlıklı olarak bağlıdır; her metriğin ağırlığı güncellenmektedir.
Lighthouse, lab ortamında (simüle edilmiş Moto G4, yavaş 4G ağ) çalıştığından gerçek kullanıcı performansından farklılık gösterebilir. Chrome DevTools → Lighthouse sekmesi, lighthouse CLI veya PageSpeed Insights üzerinden çalıştırılabilir. Elde edilen “Opportunities” ve “Diagnostics” bölümü, somut optimizasyon adımlarını ve her adımın kazandırabileceği süreyi listeler.
PageSpeed Insights (PSI)
PageSpeed Insights, aynı arayüzde hem CrUX field data’yı hem de Lighthouse lab data’yı birleştiren Google’ın web tabanlı aracıdır. Üst kısımda “Field Data” (gerçek kullanıcı verisi, CrUX) ve “Lab Data” (Lighthouse) olmak üzere iki bölüm bulunur; yeterli CrUX verisi olmayan sayfalar için yalnızca lab data gösterilir.
PSI API (ücretsiz, API anahtarı ile yüksek limit) aracılığıyla programatik olarak erişilebilir; bu sayede büyük ölçekli site denetimlerinde yüzlerce URL’nin performansını otomatik olarak taramak mümkündür. PSI’deki field data, Search Console Core Web Vitals raporuyla aynı CrUX kaynağına dayandığından Google’ın gördüğü değerle birebir örtüşür.
WebPageTest
WebPageTest, dünyanın farklı lokasyonlarından, farklı cihaz ve ağ koşullarında test çalıştırmanıza olanak tanıyan gelişmiş açık kaynak performans test aracıdır. Filmstrip görünümü, yüklemenin saniye saniye görsel ilerlemesini gösterir; Waterfall şeması ise her kaynağın ne zaman başlayıp bittiğini, hangi aşamada (DNS, bağlantı, yükleme) ne kadar süre harcandığını detaylı biçimde ortaya koyar.
SpeedIndex, WebPageTest’in en bilinen özel metriğidir ve filmstrip karelerine dayanan görsel tamamlanma oranlarını entegre eder. Test lokasyonu seçimi kritiktir; Türkiye’deki kullanıcılar için Frankfurt, İstanbul veya Londra lokasyonlarından test yapmak daha temsili sonuç üretir. WebPageTest ayrıca Core Web Vitals metriklerini de raporlar ve video karşılaştırması (filmstrip comparison) ile farklı optimizasyon senaryolarını görsel olarak kıyaslamanıza imkân tanır.
PerformanceObserver API
PerformanceObserver, tarayıcının Performance Timeline API’siyle ürettiği performans girdilerini (LCP, CLS, long tasks, navigation, resource timing vb.) programatik olarak dinlemenizi sağlar. Sayfa yüklenmesini engellemeyen asenkron bir arayüzdür ve gerçek kullanıcı monitöring (RUM) çözümlerinin temel altyapısını oluşturur.
// LCP gözlemcisi
const lcpObserver = new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP:', lastEntry.startTime, 'ms');
console.log('Element:', lastEntry.element);
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });
// Long Task gözlemcisi
const longTaskObserver = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('Long Task süresi:', entry.duration, 'ms');
}
});
longTaskObserver.observe({ type: 'longtask', buffered: true });
// CLS gözlemcisi
let clsScore = 0;
const clsObserver = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
clsScore += entry.value;
}
}
console.log('Güncel CLS skoru:', clsScore);
});
clsObserver.observe({ type: 'layout-shift', buffered: true });
buffered: true seçeneği, observer kurulmadan önce meydana gelmiş olayların da yakalanmasını sağlar; bu sayede scriptiniz geç yüklense bile sayfa başındaki LCP ya da CLS değerlerini kaçırmazsınız.
web-vitals JavaScript Kütüphanesi
Google’ın açık kaynak web-vitals kütüphanesi, tüm Core Web Vitals metriklerini (ve ilgili metrikleri) standartlaştırılmış şekilde ölçmenin en kolay yoludur. Tarayıcı uyumluluğunu, ölçüm zamanlamasını ve edge case’leri otomatik yönetir; ham PerformanceObserver kodundan çok daha güvenilir sonuç üretir.
import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'web-vitals';
function sendToAnalytics({ name, value, rating, id }) {
// Kendi analitik sunucunuza veya Google Analytics'e gönderin
console.log(`${name}: ${value} ms — ${rating}`);
// Google Analytics 4 örneği:
gtag('event', name, {
value: Math.round(name === 'CLS' ? value * 1000 : value),
metric_id: id,
metric_value: value,
metric_rating: rating,
});
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);
rating alanı 'good', 'needs-improvement' veya 'poor' değerini taşır ve eşik karşılaştırmasını otomatik yapar. id alanı ise aynı sayfa ziyareti için birden fazla raporlama olduğunda güncelleme mantığını yönetmeye yarar; özellikle CLS değeri sayfa boyunca değişebildiğinden bu alan kritiktir. Kütüphaneyi npm install web-vitals ile kurup import edebilir ya da CDN üzerinden type="module" script olarak yükleyebilirsiniz.
Chrome DevTools
Chrome DevTools, Core Web Vitals ve performans sorunlarını araştırmak için doğrudan tarayıcı içinde çalışan güçlü bir araç setidir. Performance paneli, sayfa yüklemesi veya kullanıcı etkileşimini kayıt altına alarak main thread aktivitesini, uzun görevleri, Layout ve Paint zamanlamalarını zaman çizelgesinde gösterir. Coverage sekmesi, yüklenen CSS ve JavaScript’in ne kadarının gerçekte kullanıldığını yüzde olarak raporlar; dead code tespitinde çok işe yarar.
Network sekmesindeki throttling özelliği, yavaş 4G veya Slow 3G gibi bağlantı koşullarını simüle ederek gerçek mobil kullanıcı deneyimini masaüstünde test etmenizi sağlar. Rendering sekmesindeki “Paint flashing”, “Layout Shift Regions” ve “Frame Rendering Stats” katmanları, gerçek zamanlı olarak hangi alanların reflow ve repaint yaşadığını görselleştirir. Lighthouse sekmesi ise doğrudan DevTools içinden tam Lighthouse denetimi çalıştırmanıza imkân tanır.
Lighthouse CI
Lighthouse CI (LHCI), Lighthouse denetimlerini CI/CD pipeline’larına entegre etmek için Google tarafından geliştirilmiş açık kaynak araçtır. Her pull request veya deployment sonrasında otomatik Lighthouse çalıştırarak performans regresyonlarını merge öncesinde tespit eder. Eşik değerleri (assert yapılandırması) aşıldığında CI build’i başarısız sayılır ve ekip uyarılır.
GitHub Actions, CircleCI ve Jenkins gibi yaygın CI/CD platformlarıyla entegrasyonu desteklenir. LHCI sunucusu kurulduğunda zaman serisi grafikleriyle performans trendini görselleştirir; hangi commit’in regresyona neden olduğu kolayca tespit edilebilir. Büyük ekiplerde performans bütçesi (performance budget) uygulamak ve regresyonları proaktif olarak önlemek için LHCI olmazsa olmaz bir araçtır.
RUM — Real User Monitoring (Gerçek Kullanıcı İzleme)
RUM, gerçek ziyaretçilerin tarayıcılarında ölçülen performans verisini merkezi bir platforma toplayan ve analiz eden izleme yaklaşımıdır. CrUX ücretsiz ama gecikmiş ve yalnızca Chrome kullanıcılarını kapsar; özel RUM ise tüm tarayıcıları (Safari, Firefox dahil), her URL’i ve özel segmentleri (cihaz, ülke, bağlantı türü) anlık olarak izleyebilir. web-vitals kütüphanesi, özel RUM altyapısının JavaScript tarafını oluşturan temel bileşendir.
Ticari RUM çözümleri arasında SpeedCurve, Calibre, Datadog RUM ve New Relic Browser sayılabilir. Bu araçlar p75 değerlerini segmente edilmiş biçimde (mobil/masaüstü, coğrafya, bağlantı hızı) raporlar ve anomali tespiti, alarm bildirimi gibi ek özellikler sunar. Kritik e-ticaret sayfaları veya dönüşüm hunisi adımları için özel RUM, CrUX’tan çok daha detaylı ve zamanında içgörü sağlar.
Google Sıralama Bağlamında Core Web Vitals
Bu son bölüm, performans metriklerinin arama motoru sıralamalarıyla olan doğrudan ilişkisini ele alır ve Google’ın resmi açıklamalarına dayanan bağlamı ortaya koyar.
Page Experience (Sayfa Deneyimi)
Page Experience, Google’ın bir web sayfasının kullanıcı deneyim kalitesini değerlendirmek için kullandığı sinyal kümesinin adıdır. Bu sinyal kümesi şu bileşenleri içerir: Core Web Vitals (LCP, CLS, INP), HTTPS (güvenli bağlantı), Mobile-friendliness (mobil uyumlu tasarım) ve No intrusive interstitials (agresif tam sayfa reklam veya açılır pencere yokluğu).
Google, bu sinyalleri toplu olarak kullanıcı deneyimini destekleyen bir sıralama faktörü olarak değerlendirir. Sayfa Deneyimi’nin mükemmel olması, içerik kalitesi, geri bağlantı profili ve kullanıcı intent uyumu gibi güçlü sıralama sinyallerinin yerini almaz; ancak iki benzer içeriğin yarıştığı durumlarda belirleyici bir etken olabilir. Teknik SEO hizmetlerimiz kapsamında Page Experience denetimi kapsamlı biçimde ele alınmaktadır.
Page Experience Update (Sayfa Deneyimi Güncellemesi)
Google, Page Experience Update’i mobil aramalar için Haziran–Ağustos 2021 arasında kademeli olarak hayata geçirdi. Masaüstü aramaları ise Şubat 2022’de bu güncellemenin kapsamına dahil edildi. Güncelleme aynı zamanda Google Haberler’deki “Top Stories” karuselinde AMP zorunluluğunu kaldırarak yerini Page Experience sinyallerine bıraktı; bu değişiklik, AMP benimseme baskısını önemli ölçüde azalttı.
2022 yılından bu yana INP’nin FID’in yerini alması (Mart 2024) ve eşik değerlerinde yapılan güncellemeler gibi ince ayarlar sürmektedir. Google, büyük algoritma güncellemelerini duyurmadan önce genellikle resmi Search Central Blog’da önceden bildirimde bulunur; bu nedenle Sayfa Deneyimi eşiklerini ve metrik değişikliklerini takip etmek için resmi dokümantasyonu düzenli olarak kontrol etmek önemlidir.
Sıralama Ağırlığı ve Sinyal Gücü
Google, Core Web Vitals’ın sıralama üzerindeki etkisini “mütevazı ama gerçek” olarak tanımlamıştır. Resmi açıklamalara göre CWV, içerik kalitesi ve backlink gücü gibi birincil sıralama faktörlerinin gücüne ulaşmaz; ancak belirgin biçimde ölçülebilir bir katkısı vardır. CWV’nin sıralamaya etkisini izole etmek, diğer değişkenlerin varlığı nedeniyle pratikte güçtür.
Google Search Advocates ve Search Central ekibi, CWV’nin yalnızca “içerik kalitesi eşit olduğunda” belirleyici olduğunu vurgulamıştır. Bu nedenle Core Web Vitals optimizasyonu tek başına bir strateji değil; içerik, bağlantı ve teknik SEO’yu kapsayan bütüncül teknik SEO yaklaşımının bir parçası olarak ele alınmalıdır. Bununla birlikte, ziyaretçi memnuniyeti, hemen çıkma oranı ve dönüşüm oranları üzerindeki doğrudan etkileri düşünüldüğünde iyi CWV skorları kendi başına değerlidir.
Bu sözlük, Core Web Vitals ekosistemindeki terminolojiyi eksiksiz kapsayacak biçimde hazırlanmıştır ve metrikler güncellendikçe güncel tutulacaktır. Belirli bir metriği daha derinlemesine araştırmak istiyorsanız LCP rehberi, CLS rehberi ve INP rehberi sayfalarımız kapsamlı pratik adımlar sunmaktadır. Sitenizin mevcut Core Web Vitals durumunu analiz etmek ve iyileştirme yol haritası oluşturmak için teknik SEO hizmetlerimize başvurabilirsiniz.
