Core Web Vitals Nedir, Nasıl İyileştirilir?

Core Web Vitals, Google’ın bir web sitesinin gerçek kullanıcı deneyimini (UX) ölçümlemek, sayfa hızı ve görsel kararlılık standartlarını belirlemek için kullandığı en kritik performans metrikleridir. Bir dijital ürünün başarısı, sadece estetik tasarımlara değil, sitenin ne kadar hızlı yüklendiğine ve kullanıcının etkileşimlerine ne kadar çevik yanıt verdiğine doğrudan bağlıdır. Bu teknik rehberde, "Core Web Vitals Nedir, Nasıl İyileştirilir?" sorusunun yanıtını arayan işletme sahipleri, dijital pazarlama yöneticileri ve teknik karar vericiler için performans metriklerini derinlemesine analiz ediyor ve sürdürülebilir bir optimizasyon stratejisi sunuyoruz.

Core Web Vitals (Önemli Web Verileri) Nedir ve Neden Kritik Bir İşletme Riskidir?

Core Web Vitals, arama motoru devinin "Sayfa Deneyimi" (Page Experience) algoritma güncellemelerinin merkezinde yer alan üç temel performans metriğinden oluşur. Bu metrikler jenerik hız testlerinden farklı olarak, web sitenizin kod yapısının tarayıcı tarafından ne kadar verimli işlendiğini ve son kullanıcının ekranında nasıl bir fiziksel davranış sergilediğini ölçer. Google, kullanıcıların yavaş açılan, tıklamalara geç yanıt veren veya yüklenirken içeriği kayan web sitelerinden hızla uzaklaştığını tespit etmiştir. Bu nedenle, ilgili metrikleri teknik birer lüks olmaktan çıkarıp doğrudan bir organik görünürlük kriteri haline getirmiştir.

İşletmeler ve dijital karar vericiler için düşük Core Web Vitals skorları sadece teknik bir borç (technical debt) değil, aynı zamanda ciddi bir finansal risktir. Yavaş yüklenen ve kararsız davranan e-ticaret siteleri ya da kurumsal platformlar, daha yüksek hemen çıkma oranları (bounce rate) ve ciddi oranda düşen dönüşüm oranları (conversion rates) ile karşı karşıya kalır. Yapılan endüstriyel araştırmalar, sayfa yüklenme süresindeki her 100 milisaniyelik gecikmenin dönüşüm oranlarında ortalama %7 ila %10 arasında bir kayba yol açtığını göstermektedir. Dolayısıyla, bu metriklerin optimize edilmesi doğrudan müşteri edinme maliyetlerini (CAC) düşürmeye ve yatırım getirisini (ROI) artırmaya yardımcı olur.

Teknik SEO perspektifinden bakıldığında ise Core Web Vitals, Google’ın sıralama algoritmalarında doğrudan ağırlığa sahip bir sayfa deneyimi optimizasyonu sinyalidir. Sitenizin teknik altyapısı ne kadar iyi kurgulanmış olursa olsun, rakiplerinizin performans verileri sizinkilerden üstünse, organik arama görünürlüğünde geriye düşmeniz kaçınılmazdır. Özellikle mobil öncelikli indeksleme (mobile-first indexing) çağında, mobil cihazlardaki performans yetersizlikleri masaüstü sıralamalarını da aşağı çekmektedir. Bu durum, işletmeler için organik trafik kaybı ve dolayısıyla gelir kaybı anlamına gelmektedir.

2024 ve Sonrası Standartlarıyla Temel Core Web Vitals Metrikleri

Web standartları geliştikçe ve kullanıcı alışkanlıkları değiştikçe Google da performans metriklerini daha gerçekçi senaryolara uyarlamaktadır. Günümüz itibarıyla Core Web Vitals üç temel ayaktan oluşmaktadır: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) ve Cumulative Layout Shift (CLS). Bu metriklerin her biri, sayfa yükleme sürecinin farklı bir evresine odaklanarak bütünsel bir kullanıcı deneyimi şeması çizer.

Largest Contentful Paint (LCP): Yükleme Performansı ve Optimizasyonu

Largest Contentful Paint (LCP), bir web sayfasının ana içeriğinin (genellikle büyük bir görsel kahraman alanı, ana başlık veya video bloğu) tarayıcı ekranında görünür hale gelme süresini ölçer. LCP, kullanıcının sayfanın yüklendiğine dair algısını doğrudan temsil ettiği için yükleme performansının birincil göstergesidir. İdeal bir LCP skoru 2.5 saniye veya daha kısa olmalıdır. 2.5 saniye ile 4.0 saniye arasındaki değerler iyileştirilmesi gereken alanlara işaret ederken, 4.0 saniyenin üzerindeki süreler doğrudan başarısız olarak kabul edilir.

LCP skorunu olumsuz etkileyen unsurların başında yavaş sunucu yanıt süresi (TTFB), oluşturmayı engelleyen kaynaklar (render-blocking), yavaş kaynak yükleme süreleri ve istemci taraflı render (client-side rendering) süreçleri gelir. Optimizasyon için öncelikle LCP elementinin doğru tespit edilmesi gerekir. Örneğin, bir e-ticaret ürün sayfasındaki ana ürün görseli genellikle LCP elemanıdır. Bu görselin tembel yükleme (lazy loading) kapsamı dışında tutulması ve tarayıcıya fetchpriority="high" özniteliğiyle önceliklendirilerek sunulması LCP süresini dramatik şekilde düşürecektir.

Interaction to Next Paint (INP): Etkileşim Kararlılığı

Interaction to Next Paint (INP), Mart 2024 itibarıyla First Input Delay (FID) metriğinin yerini alarak resmi bir Core Web Vitals metriği haline gelmiştir. FID yalnızca ilk kullanıcı etkileşimini ölçerken, INP kullanıcının sayfada geçirdiği tüm süre boyunca gerçekleştirdiği tüm tıklama, dokunma ve klavye etkileşimlerinin gecikme sürelerini analiz eder ve en kötü gecikmeyi temel alır. Bu nedenle, sayfa içi etkileşim kalitesini çok daha gerçekçi bir şekilde yansıtır. İyi bir kullanıcı deneyimi için hedeflenen INP değeri 200 milisaniye veya altıdır.

INP değerini düşürmenin anahtarı, tarayıcının ana iş parçacığını (main thread) bloke eden uzun süreli JavaScript görevlerini (Long Tasks - 50ms üzeri süren işlemler) bölmek veya ertelemektir. Ağır üçüncü taraf komut dosyaları, karmaşık CSS animasyonları ve büyük DOM boyutu etkileşimlerin işlenmesini ve ekrana yansıtılmasını geciktirir. Web Workers kullanımı, kullanılmayan JavaScript kodlarının elenmesi (tree-shaking) ve dinamik içe aktarma (dynamic import) yöntemleri INP skorunu iyileştirmek için kullanılan temel teknik yaklaşımlardır.

Cumulative Layout Shift (CLS): Görsel Kararlılık ve Tasarım Hataları

Cumulative Layout Shift (CLS), web sayfasının yüklenme süreci boyunca veya kullanım esnasında meydana gelen beklenmedik düzen kaymalarını ölçen görsel kararlılık metriğidir. Kullanıcı tam bir butona tıklamak üzereyken üstte aniden beliren bir reklam veya görsel yüzünden butonun aşağı kayması ve kullanıcının yanlış yere tıklaması, tipik bir CLS problemidir. Google bu durumun önüne geçmek için maksimum CLS skorunu 0.1 olarak belirlemiştir. 0.25'in üzerindeki değerler ise kullanıcı deneyimi açısından kabul edilemez olarak değerlendirilir.

Yüksek CLS skoruna neden olan temel tasarım hataları arasında boyutları (width ve height) önceden tanımlanmamış görseller ve videolar, dinamik olarak sayfaya enjekte edilen reklam alanları, sonradan yüklenen yazı tiplerinin (web fonts) oluşturduğu FOIT/FOUT (yazı tipinin görünmemesi veya değişmesi) durumları yer alır. Modern web tasarımında, CSS yardımıyla elemanlar için @@CODE0@@ tanımlamak, dinamik alanlar için yer tutucu (skeleton screen) tasarımlar hazırlamak ve yazı tiplerini @@CODE1@@ ile optimize etmek görsel kararlılığı sağlamanın en güvenli yollarıdır.

Core Web Vitals Ölçümlemesi İçin Kullanılması Gereken Endüstri Standartları

Bir web sitesinin performansını optimize etmeden önce, mevcut durumun endüstri standartlarına uygun araçlarla analiz edilmesi ve doğru verilerin toplanması gerekir. Web performans dünyasında veriler "Saha Verileri" (Field Data) ve "Laboratuvar Verileri" (Lab Data) olmak üzere ikiye ayrılır. Bu iki veri setinin farkını ve ne zaman kullanılacağını bilmek, doğru strateji kurgulamanın temel taşıdır.

Saha Verileri İçin Google Search Console Kullanımı

Saha verileri (Field Data), Chrome Kullanıcı Deneyimi Raporu (CrUX) aracılığıyla gerçek kullanıcıların web sitenizde deneyimlediği performansı yansıtır. Coğrafi konum, cihaz türü (mobil/masaüstü) ve ağ bağlantı hızı gibi gerçek dünya koşullarını içerdiği için Google’ın sıralama algoritmalarında doğrudan dikkate aldığı veri türü budur. Google Search Console üzerindeki "Önemli Web Verileri" raporu, sitenizdeki hangi URL gruplarının "İyi", "İyileştirilmesi Gerekiyor" veya "Zayıf" kategorisinde olduğunu doğrudan CrUX veritabanından çekerek size sunar.

Saha verilerinin en büyük sınırlılığı, düşük trafikli sitelerde veya yeni açılan sayfalarda yeterli veri birikene kadar raporlama yapılamamasıdır. Ayrıca, saha verileri gerçek zamanlı değildir; genellikle son 28 günlük yuvarlanan bir ortalamayı yansıtır. Bu nedenle, yaptığınız bir optimizasyonun Google Search Console üzerindeki etkisini görmek için birkaç hafta beklemeniz gerekebilir. Teknik analiz süreçlerinde bu gecikmeyi yönetmek adına "Düzeltmeyi Doğrula" (Validate Fix) seçeneği kullanılarak süreç hızlandırılabilir.

Laboratuvar Verileri İçin PageSpeed Insights ve Lighthouse Denetimleri

Laboratuvar verileri (Lab Data), kontrollü bir ortamda, belirli bir cihaz ve ağ simülasyonu altında gerçekleştirilen anlık test sonuçlarıdır. Lighthouse ve PageSpeed Insights, geliştiricilere anlık hata ayıklama (debugging) ve hızlı geri bildirim imkanı tanır. Bir kod değişikliği yaptıktan hemen sonra sayfa hızı skorunuzun nasıl değiştiğini görmek için laboratuvar verilerini kullanmalısınız. Lighthouse, sayfa üzerinde sanal bir tarayıcı çalıştırarak oluşturmayı engelleyen kaynaklar (render-blocking) gibi teknik aksaklıkları tespit eder ve çözüm önerileri sunar.

Ancak laboratuvar ortamı gerçek kullanıcı davranışlarını taklit edemez. Örneğin, bir kullanıcının sayfa yüklendikten sonra yaptığı kaydırma ve tıklama eylemlerini laboratuvar testleri tam olarak gerçekleştiremediği için laboratuvar verilerindeki INP skoru ile gerçek dünyadaki saha INP skoru birbirinden farklı çıkabilir. Bu sebeple, laboratuvar testlerini bir geliştirme ve kontrol aracı olarak konumlandırmalı, nihai başarı kriteri olarak ise her zaman saha verilerini (CrUX) baz almalısınız.

Core Web Vitals Optimizasyonunda Sık Yapılan Kurumsal Hatalar

Büyük ölçekli ve kurumsal web projelerinde performans optimizasyonu süreçleri genellikle pazarlama, tasarım ve yazılım ekiplerinin farklı öncelikleri nedeniyle sekteye uğrar. Bu karmaşık süreçte, kısa vadeli çözümler üretilmeye çalışılırken uzun vadede performansı daha da kötüleştiren yapısal hatalar yapılmaktadır.

En yaygın hatalardan biri, oluşturmayı engelleyen kaynaklar (render-blocking) konusunun göz ardı edilmesidir. Kurumsal sitelerde sıklıkla kullanılan çok sayıda CSS kütüphanesi (Bootstrap, Tailwind vb.) ve JavaScript bağımlılıkları, kritik olmayan sayfalarda dahi sayfa başlangıcında yüklenmeye zorlanır. Tarayıcı bu dosyaları tamamen indirip işlemeden sayfayı ekrana çizmeye (paint) başlayamaz. Bu durum LCP süresini doğrudan uzatır. Kritik CSS (Critical CSS) uygulamasının yapılmaması ve tüm stil dosyalarının tek bir devasa paket halinde sunulması bu hatanın temel kaynağıdır.

İkinci büyük hata ise tembel yükleme (lazy loading) teknolojisinin yanlış kullanımıdır. Görsel optimizasyonu amacıyla kullanılan bu teknik, yanlışlıkla sayfanın en üstünde (above the fold) yer alan ve doğrudan LCP elemanı olan kahraman (hero) görsellere de uygulanır. Tarayıcı, sayfa yüklenirken bu görselin hemen yüklenmesi gerektiğini anlamak yerine, JavaScript'in devreye girip görseli yüklemesini bekler. Bu durum LCP skorunda ciddi bir gerilemeye neden olur. Doğru yaklaşım, ilk ekranda görünen görsellere asla tembel yükleme uygulamamak, hatta bunları rel="preload" ile önceden yüklemektir.

Son olarak, pazarlama ve analitik ekiplerinin siteye eklediği üçüncü taraf komut dosyalarının (Third-party scripts) kontrolsüzce büyümesi, INP ve CLS skorlarını tahrip eder. Isı haritaları (Hotjar vb.), canlı destek chat araçları, reklam pikselleri (Meta, Google Tag Manager) tarayıcının ana iş parçacığını aşırı derecede meşgul eder. Bu betikler doğru yönetilmediğinde (örneğin @@CODE0@@ veya @@CODE1@@ öznitelikleri kullanılmadığında veya Google Tag Manager üzerinden optimize edilmeden yüklendiğinde) kullanıcıların sayfadaki tıklama eylemlerine yanıt verilmesini engeller ve INP değerini kabul edilemez seviyelere çıkarır.

Geliştiriciler İçin Adım Adım Teknik İyileştirme Yol Haritası

Core Web Vitals skorlarında sürdürülebilir bir başarı elde etmek için sistematik ve aşamalı bir teknik yol haritası izlenmelidir. Optimizasyon süreci, sunucu seviyesinden başlayıp tarayıcının son pikseli ekrana çizmesine kadar uzanan bir zincirdir.

Sunucu Yanıt Süresi (TTFB) ve Kritik CSS Optimizasyonu

İlk aşamada odaklanılması gereken nokta sunucu yanıt süresi (TTFB) değeridir. Sunucu, tarayıcıdan gelen isteğe ne kadar geç yanıt verirse, sonraki tüm süreçler o kadar gecikir. TTFB'yi optimize etmek için gelişmiş sunucu önbellekleme (Redis, Varnish vb.) mekanizmaları kullanılmalı, veritabanı sorguları optimize edilmeli ve statik içerikler için dinamik bir CDN (Content Delivery Network) ağı kurulmalıdır. HTTP/2 ve modern HTTP/3 protokollerinin sunucu tarafında aktif edilmesi, tarayıcı ile sunucu arasındaki veri transferinin çok daha hızlı ve eşzamanlı gerçekleşmesini sağlar.

TTFB optimize edildikten sonra tarayıcının sayfayı oluşturmaya başlaması için kritik CSS (Critical CSS) tekniği uygulanmalıdır. Bu teknik, sayfanın yalnızca ilk ekranını (above the fold) oluşturmak için gereken minimum CSS kurallarının belirlenerek HTML belgesinin @@CODE0@@ bölümüne @@CODE1@@ etiketleri içinde doğrudan gömülmesini (inlining) içerir. Geriye kalan ve sayfa kaydırıldıkça ihtiyaç duyulacak büyük stil dosyaları ise asenkron olarak, tarayıcıyı bloke etmeyecek şekilde arka planda yüklenir.

JavaScript Optimizasyonu ve DOM Boyutunun Küçültülmesi

İkinci aşama, tarayıcı üzerindeki en büyük işlem yükünü oluşturan JavaScript kodlarının ve DOM yapısının temizlenmesidir. Tarayıcıların HTML belgesini işleyerek oluşturduğu Document Object Model (DOM) boyutu ne kadar büyük olursa, sayfa o kadar hantal çalışır. Google standartlarına göre bir sayfadaki toplam DOM düğümü (node) sayısı 1000'in altında olmalı, maksimum derinlik ise 32'yi aşmamalıdır. Gereksiz iç içe geçmiş <div> yapılarından kaçınmak ve semantik HTML kullanmak DOM boyutunu küçültmek için kritik önem taşır.

JavaScript optimizasyonunda ise öncelikle kullanılmayan kodların (Unused JS) tespit edilip elenmesi gerekir. Büyük kütüphanelerin tamamını yüklemek yerine sadece ihtiyaç duyulan modülleri yüklemek (tree-shaking), dinamik yükleme ile sadece ilgili sayfada çalışan kodları çağırmak ve modern es6+ kodlama standartlarını kullanmak tarayıcının yükünü hafifletir. Ayrıca, etkileşimlerin kilitlenmesini önlemek amacıyla, kritik olmayan tüm JavaScript görevleri @@CODE0@@ veya @@CODE1@@ API'leri kullanılarak tarayıcının boş kaldığı anlara ertelenmelidir. Bu sayede INP performansı iyileştirilir.

Sürdürülebilir Performans İçin Stratejik Eylem Planı

Web performansı, bir kez yapılıp tamamlanan bir proje değil; sürekli izlenmesi, korunması ve geliştirilmesi gereken dinamik bir süreçtir. Sitenize eklenen yeni bir özellik, pazarlama ekibinin entegre ettiği yeni bir piksel veya tasarım tarafında yapılan küçük bir değişiklik, tüm Core Web Vitals skorlarınızı bir günde olumsuz yöne çevirebilir. Bu nedenle, işletmelerin sürdürülebilir bir performans kültürü benimsemeleri gerekir.

Bu sürdürülebilirliği sağlamanın ilk adımı, yazılım geliştirme süreçlerine bir "Performans Bütçesi" (Performance Budget) dahil etmektir. Performans bütçesi, projenin teknik sınırlarını çizer. Örneğin; "Toplam JavaScript boyutu 150 KB'ı geçemez", "LCP görsel boyutu maksimum 80 KB olabilir" veya "Herhangi bir sayfadaki toplam istek sayısı 50'yi aşamaz" gibi kurallar belirlenir. Bu bütçe sınırları aşıldığında, CI/CD (Sürekli Entegrasyon / Sürekli Dağıtım) süreçlerinde Lighthouse CI gibi otomasyon araçları devreye girmeli ve bütçeyi aşan güncellemelerin canlı ortama (production) geçmesini otomatik olarak engellemelidir.

Ayrıca, teknik ekipler ile pazarlama ve ürün yönetimi ekipleri arasında net bir iletişim köprüsü kurulmalıdır. Ürün yöneticileri veya pazarlama uzmanları siteye yeni bir üçüncü taraf araç eklemek istediğinde, bu aracın olası INP ve LCP etkileri teknik ekipler tarafından önceden test edilmelidir. Performans odaklı bu kurumsal yaklaşım, sitenizin zaman içinde teknik olarak eskimesini ve yavaşlamasını önleyerek kullanıcı deneyimini ve SEO başarınızı uzun vadede güvence altına alacaktır.