Core Web Vitals: LCP, INP ve CLS ile performansı ölçülebilir kılmak

Bir web sitesinin hızlı olduğunu söylemek kolaydır; bunu kanıtlamak ise ölçülebilir metrikler gerektirir. Google'ın Core Web Vitals (CWV) metrikleri tam olarak bunu yapar: kullanıcının gerçekte deneyimlediği yükleme hızını, etkileşim tepkiselliğini ve görsel kararlılığı somut sayılara dönüştürür. Üstelik bu metrikler yalnızca kullanıcı deneyimini değil, arama sıralamasını da doğrudan etkiler. Bu rehberde LCP, INP ve CLS metriklerini tek tek açıklıyor, en yaygın darboğazları gösteriyor ve özellikle Next.js projelerinde uygulanabilir iyileştirmeleri kod örnekleriyle paylaşıyoruz.

Performans optimizasyonu çoğu zaman "his" üzerinden tartışılır: "Site bana yavaş geldi." Oysa Core Web Vitals bu öznel yargıyı ortadan kaldırır. Hedefler nettir: LCP 2,5 saniyenin altında, INP 200 milisaniyenin altında ve CLS 0,1'in altında olmalıdır. Bu üç sayının altına inmek, hem kullanıcının hem de Google'ın gözünde "hızlı site" tanımını karşılamak demektir. Şimdi bu metrikleri ve onları nasıl iyileştireceğinizi derinlemesine inceleyelim.

Core Web Vitals Nedir ve Neden Önemlidir?

Core Web Vitals, Google'ın kullanıcı deneyimini ölçmek için tanımladığı, sayfa hızı ve etkileşim kalitesine odaklanan bir metrik setidir. Üç temel metrikten oluşur: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ve CLS (Cumulative Layout Shift). Bu üçlü, bir sayfanın ne kadar hızlı yüklendiğini, kullanıcı etkileşimlerine ne kadar çabuk yanıt verdiğini ve görsel olarak ne kadar kararlı olduğunu birlikte ölçer.

Bu metriklerin önemi iki katmanlıdır. Birincisi, doğrudan iş sonuçlarını etkiler: yavaş yüklenen sayfalar daha yüksek hemen çıkma oranına ve daha düşük dönüşüme yol açar. Saniyelerle ölçülen gecikmeler, e-ticarette doğrudan kayıp satış demektir. İkincisi, Core Web Vitals Google'ın sıralama sinyallerinden biridir; "page experience" değerlendirmesinin parçası olarak organik görünürlüğü etkiler. Yani CWV'yi iyileştirmek, hem kullanıcıyı memnun eder hem de SEO performansını yükseltir.

Türkiye'de mobil internet kullanımının yaygınlığı bu metrikleri daha da kritik kılar. Kullanıcıların önemli bir kısmı sitenize değişken hızdaki mobil bağlantılarla ulaşır. Masaüstünde harika görünen bir site, orta seviye bir telefonda ve sıradan bir mobil bağlantıda kabul edilemez derecede yavaş olabilir. Bu nedenle optimizasyonu daima gerçek dünya koşullarını düşünerek yapmak gerekir.

Saha Verisi (Field Data) ve Laboratuvar Verisi (Lab Data) Farkı

Core Web Vitals'ı doğru yorumlamak için iki farklı veri türünü ayırt etmek şarttır. Bu ayrımı kaçırmak, "Lighthouse'da 100 aldım ama Search Console hâlâ düşük diyor" gibi kafa karışıklıklarının temel sebebidir.

Laboratuvar verisi (lab data), kontrollü bir ortamda, sabit bir cihaz ve ağ profili simülasyonuyla toplanır. Lighthouse ve PageSpeed Insights'ın simülasyon modu bu tür veridir. Tekrarlanabilir ve hata ayıklamak için idealdir, ancak gerçek kullanıcıların yaşadığını birebir yansıtmaz.

Saha verisi (field data), gerçek kullanıcılardan toplanan anonim performans ölçümleridir. Google bunu Chrome User Experience Report (CrUX) üzerinden toplar ve Search Console ile PageSpeed Insights'ta gösterir. Sıralama sinyali olarak kullanılan veri budur. Saha verisi, son 28 günlük gerçek ziyaretçi deneyiminin 75. yüzdelik dilimini esas alır; yani kullanıcılarınızın dörtte üçünün gördüğü değerdir.

Pratik sonuç şudur: laboratuvar verisini geliştirme sırasında hata ayıklamak için, saha verisini ise gerçek başarıyı ölçmek için kullanın. İkisi arasında ciddi fark varsa, genellikle gerçek kullanıcı cihazları ve ağ koşulları simülasyondan daha zorludur.

LCP (Largest Contentful Paint): Yükleme Hızı

LCP, görünür alandaki en büyük içerik öğesinin (genellikle bir kapak görseli, video posteri ya da büyük bir başlık bloğu) ekranda boyanma süresini ölçer. Kısacası kullanıcının "sayfa yüklendi" hissini ne zaman aldığını gösterir. Hedef değerler şöyledir:

Metrik	İyi	İyileştirme Gerekli	Kötü
LCP	2,5 saniyenin altında	2,5 - 4,0 saniye	4,0 saniyenin üstünde
INP	200 ms altında	200 - 500 ms	500 ms üstünde
CLS	0,1 altında	0,1 - 0,25	0,25 üstünde

LCP'yi yavaşlatan en yaygın nedenler: optimize edilmemiş büyük görseller, yavaş sunucu yanıt süresi (TTFB), render'ı engelleyen CSS ve JavaScript, ve geç yüklenen web fontları. İyi haber, bunların her birinin çözümü bellidir.

LCP'yi iyileştirmek için temel adımlar:

• En büyük görseli modern formatta (WebP veya AVIF) ve doğru boyutta sunun.
• LCP öğesini asla tembel yüklemeyin (lazy load); aksine öncelik verin.
• Kritik görsel için ön yükleme (preload) ipucu ekleyin.
• Sunucu yanıt süresini önbellekleme ve CDN ile düşürün.
• Render'ı engelleyen kaynakları azaltın ve kritik CSS'i satır içi (inline) verin.

Next.js'te kapak görselini önceliklendirmek için Image bileşeninin priority özelliği tam olarak bu işe yarar:

import Image from "next/image"

export default function Hero() {
  return (
    <Image
      src="/kapak.webp"
      alt="Sayfa kapak görseli"
      width={1200}
      height={675}
      priority
    />
  )
}

Buradaki priority özelliği, Next.js'in bu görseli otomatik olarak ön yüklemesini ve tembel yükleme dışında tutmasını sağlar; bu da LCP öğesinin mümkün olan en erken anda boyanmasına yardımcı olur.

INP (Interaction to Next Paint): Etkileşim Tepkiselliği

INP, 2024'te eski FID (First Input Delay) metriğinin yerini alan, etkileşim tepkiselliğini ölçen metriktir. Kullanıcının bir butona tıklaması, bir menüyü açması ya da bir alana yazı yazması gibi etkileşimlerden sonra ekranın güncellenmesinin (bir sonraki boyamanın) ne kadar sürdüğünü ölçer. FID yalnızca ilk etkileşimin gecikmesine bakarken, INP sayfa ömrü boyunca tüm etkileşimleri değerlendirir; bu da onu çok daha gerçekçi bir tepkisellik göstergesi yapar.

Hedef nettir: INP 200 milisaniyenin altında olmalıdır. Bu eşiğin üzerinde kullanıcı, tıkladığında "bir şey olmuyor" hissine kapılır ve genellikle tekrar tıklar; bu da deneyimi daha da bozar.

INP'yi bozan başlıca neden, ana iş parçacığını (main thread) uzun süre meşgul eden ağır JavaScript çalışmasıdır. Tarayıcı tek bir ana iş parçacığında hem JavaScript çalıştırır hem de ekranı boyar; uzun süren bir hesaplama bu iş parçacığını bloke ederse, kullanıcının etkileşimi sıraya girer ve gecikir. INP'yi iyileştirmek için stratejiler:

• Uzun JavaScript görevlerini küçük parçalara bölün; ağır işi gerektiğinde web worker'a taşıyın.
• Gereksiz JavaScript'i kaldırın ve paket boyutunu küçültün (code splitting).
• Sık tetiklenen olaylarda debounce/throttle kullanın.
• Pahalı yeniden render'ları önleyin; gereksiz durum güncellemelerinden kaçının.

Ağır bir hesaplamayı kullanıcı etkileşimini bloke etmeden yürütmek için işi ertelemek etkili bir tekniktir. Aşağıdaki örnekte, kritik olmayan bir iş tarayıcının boş zamanına bırakılır:

button.addEventListener("click", () => {
  // Kritik UI güncellemesi hemen yapılır
  gosterYukleniyor()

  // Ağır iş, ana iş parçacığını bloke etmemesi için ertelenir
  if ("requestIdleCallback" in window) {
    requestIdleCallback(() => {
      agirHesaplamaYap()
    })
  } else {
    setTimeout(agirHesaplamaYap, 0)
  }
})

Bu yaklaşımla kullanıcı tıkladığı anda arayüz tepki verir, ağır iş ise arka planda, tepkiselliği bozmadan tamamlanır.

CLS (Cumulative Layout Shift): Görsel Kararlılık

CLS, sayfa yüklenirken öğelerin beklenmedik biçimde yer değiştirmesini ölçer. Herkesin yaşadığı o sinir bozucu deneyimi düşünün: bir butona tam tıklayacakken üstte geç yüklenen bir reklam ya da görsel araya girer, içerik aşağı kayar ve siz yanlış yere tıklarsınız. İşte CLS bu kaymaların toplam etkisini puanlar. Hedef değer 0,1'in altındadır.

CLS'in en yaygın nedenleri şunlardır: boyutu belirtilmemiş görseller ve videolar, dinamik olarak enjekte edilen içerik (reklam, banner, çerez bildirimi), geç yüklenen ve metni kaydıran web fontları, ve boyutu rezerve edilmemiş gömülü içerikler (iframe, widget).

CLS'i düzeltmenin temel mantığı, içerik gelmeden önce ona ayrılacak yeri rezerve etmektir. Pratik çözümler:

• Tüm görsellere ve videolara genişlik ve yükseklik (ya da en-boy oranı) tanımlayın.
• Dinamik içerik için yer tutucu (placeholder) alanları önceden rezerve edin.
• Web fontlarını font-display: swap ile yükleyip metin kaymasını sınırlayın.
• Yeni içeriği mevcut içeriğin üstüne değil, kullanıcı etkileşimiyle ekleyin.

CSS ile bir medya öğesine en-boy oranı vererek, görsel yüklenmeden önce yerinin rezerve edilmesini garanti edebilirsiniz:

.kapak-gorsel {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

Bu kısa kural sayesinde tarayıcı, görselin gerçek pikselleri gelmeden önce 16:9 oranında bir alanı rezerve eder ve içerik kaymaz. Next.js Image bileşeninde width ve height vermek de aynı amaca hizmet eder; bileşen bu değerlerden en-boy oranını otomatik hesaplayıp kaymayı önler.

Core Web Vitals Nasıl Ölçülür? Araçlar ve Yöntemler

Optimizasyona başlamadan önce mevcut durumu doğru ölçmek gerekir; çünkü ölçemediğiniz şeyi iyileştiremezsiniz. Neyse ki Core Web Vitals için hem ücretsiz hem güçlü araçlar mevcuttur. Her birinin farklı bir amacı vardır:

• PageSpeed Insights: Hem laboratuvar hem saha verisini bir arada gösterir. Hızlı genel değerlendirme için ilk durağınız olmalı.
• Google Search Console: "Önemli Web Verileri" raporu, sitenizin tüm sayfalarının saha verisini gruplar halinde gösterir. Gerçek performansı izlemek için en önemli kaynaktır.
• Lighthouse: Chrome DevTools içinde yerleşik gelir; laboratuvar ortamında ayrıntılı hata ayıklama ve öneriler sunar.
• Chrome DevTools Performance sekmesi: Uzun görevleri, render bloklarını ve düzen kaymalarını kare kare incelemenizi sağlar.
• web-vitals kütüphanesi: Gerçek kullanıcılarınızdan kendi analitik sisteminize CWV verisi göndermenizi sağlar.

Üretim ortamında gerçek kullanıcı verisini toplamak isterseniz, Google'ın web-vitals kütüphanesi bunu birkaç satırla yapar:

import { onLCP, onINP, onCLS } from "web-vitals"

function raporla(metric) {
  // Metrik verisini kendi analitik uç noktanıza gönderin
  const veri = JSON.stringify(metric)
  navigator.sendBeacon("/analytics", veri)
}

onLCP(raporla)
onINP(raporla)
onCLS(raporla)

Bu yöntemle simülasyona değil, kendi kullanıcılarınızın gerçek cihaz ve bağlantılarından gelen veriye dayanarak karar verirsiniz. Saha verisi ile laboratuvar verisi arasındaki farkı en net bu şekilde görürsünüz.

Next.js Projelerinde Pratik Performans İyileştirmeleri

Next.js, performans için güçlü araçlar sunan modern bir çerçevedir; ancak bu araçları doğru kullanmak gerekir. Aksi halde framework'ün avantajları boşa gider. Aşağıda, Core Web Vitals'ı doğrudan etkileyen, sahada en çok fark yaratan uygulamaları topladık.

Görsel optimizasyonu için next/image kullanın. Bu bileşen, görselleri otomatik olarak doğru boyutta, modern formatta ve tembel yükleme ile sunar. LCP öğesi için priority, geri kalanı için varsayılan tembel yükleme davranışı idealdir.

Font optimizasyonu için next/font kullanın. Bu modül, fontları derleme zamanında kendi sunucunuzdan sunar ve düzen kaymasını önleyecek şekilde yapılandırır:

import { Inter } from "next/font/google"

const inter = Inter({
  subsets: ["latin"],
  display: "swap",
})

export default function RootLayout({ children }) {
  return (
    <html lang="tr" className={inter.className}>
      <body>{children}</body>
    </html>
  )
}

Sunucu bileşenlerini (Server Components) tercih edin. Next.js App Router'da varsayılan olarak gelen sunucu bileşenleri, JavaScript'i istemciye göndermeden çalışır; bu da paket boyutunu küçültür ve INP'yi iyileştirir. İstemci tarafı etkileşim gerçekten gerektiğinde "use client" yönergesini yalnızca o bileşende kullanın.

Dinamik içe aktarma (dynamic import) ile kod bölün. Sayfanın ilk yüklemesinde gerekmeyen ağır bileşenleri gerektiğinde yükleyin:

import dynamic from "next/dynamic"

const AgirGrafik = dynamic(() => import("../components/AgirGrafik"), {
  loading: () => <p>Yukleniyor...</p>,
  ssr: false,
})

Bu sayede ağır grafik kütüphanesi yalnızca ihtiyaç duyulduğunda indirilir, ilk yüklemenin LCP ve INP değerlerini aşağı çekmez.

Tüm bu tekniklerin doğru bir mimariyle birlikte kurgulanması kritiktir. Performansı baştan tasarımın parçası yapan profesyonel bir web geliştirme yaklaşımı, sonradan yapılacak yamaların çok ötesinde kalıcı sonuç verir.

Sunucu Tarafı ve Altyapı Optimizasyonları

Core Web Vitals tartışmaları çoğunlukla ön yüze odaklanır, ancak performansın önemli bir kısmı sunucuda ve altyapıda belirlenir. Özellikle LCP'nin ilk bileşeni olan TTFB (Time To First Byte), tamamen sunucu ve ağ performansına bağlıdır. Sunucu isteğe ne kadar geç yanıt verirse, kullanıcının her şeyi o kadar geç görmeye başladığını unutmayın.

Altyapı tarafında fark yaratan başlıca uygulamalar şunlardır: içerik dağıtım ağı (CDN) kullanarak içeriği kullanıcıya coğrafi olarak yakın sunuculardan sunmak, statik içerik için agresif önbellekleme yapmak, HTTP/2 veya HTTP/3 protokollerini etkinleştirmek, görselleri ve statik varlıkları sıkıştırmak (Brotli/Gzip), ve veri tabanı sorgularını optimize etmek. Türkiye'deki kullanıcılara hizmet veriyorsanız, sunucu konumunun ve CDN kenar noktalarının ülkeye yakınlığı TTFB üzerinde gözle görülür etki yaratır.

Bu altyapı katmanının doğru kurulması, sürekli izlenmesi ve yük altında stabil kalması için sağlam bir DevOps disiplini gerekir. Önbellekleme stratejileri, otomatik ölçeklenme ve dağıtım hatları gibi konularda bulut ve DevOps hizmetlerimiz, performansın yalnızca lansman gününde değil, trafik arttıkça da korunmasını sağlar.

Üçüncü Taraf Scriptlerin ve Reklamların Etkisi

Bir sitenin performansını en çok bozan etkenlerden biri, çoğu zaman geliştiricinin doğrudan yazmadığı kodlardır: üçüncü taraf scriptler. Analitik araçları, reklam ağları, sohbet widget'ları, sosyal medya gömülü içerikleri, ısı haritaları ve A/B test araçları; her biri sayfaya ek JavaScript yükler ve hepsi performansı aşağı çeker. Bu scriptlerin toplamı, sıklıkla sitenin kendi kodundan daha ağırdır.

Üçüncü taraf scriptlerin üç temel zararı vardır. Birincisi, ana iş parçacığını meşgul ederek INP'yi bozar. İkincisi, geç ve kontrolsüz yüklenerek CLS'e yol açar; örneğin geç gelen bir reklam, içeriği aşağı kaydırır. Üçüncüsü, harici sunuculardan yüklendikleri için TTFB ve LCP üzerinde dolaylı baskı yaratır.

Bu scriptleri tamamen kaldırmak çoğu zaman mümkün değildir, ancak etkileri yönetilebilir. Pratik stratejiler şunlardır: gerçekten gerekli olmayan scriptleri kaldırmak, kalanları async ya da defer ile yüklemek, kritik olmayanları kullanıcı etkileşiminden sonra (örneğin sohbet widget'ını ilk tıklamada) yüklemek ve reklam alanlarına sabit yükseklik vererek kaymayı önlemek. Next.js'te harici scriptleri kontrollü yüklemek için Script bileşeni kullanılır:

import Script from "next/script"

export default function Layout({ children }) {
  return (
    <>
      {children}
      <Script
        src="https://example.com/analytics.js"
        strategy="lazyOnload"
      />
    </>
  )
}

Buradaki strategy değeri, scriptin ne zaman yükleneceğini belirler. lazyOnload, scripti sayfa boşta kaldığında en son yükleyerek kritik metrikleri korur; afterInteractive ise sayfa etkileşime hazır olduktan hemen sonra yükler.

Kaynak İpuçları (Resource Hints) ile Hızlandırma

Tarayıcıya gelecekte neye ihtiyaç duyacağını önceden söylemek, performansı düşük maliyetle iyileştiren güçlü bir tekniktir. Kaynak ipuçları (resource hints) tam olarak bunu yapar: tarayıcının kritik kaynakları erken keşfetmesini ve bağlantıları önceden kurmasını sağlar. Doğru kullanıldığında LCP üzerinde belirgin etki yaratır.

Başlıca kaynak ipuçları ve kullanım amaçları:

• preconnect: Harici bir kaynağa (örneğin font ya da CDN sunucusu) bağlantıyı önceden kurar; el sıkışma gecikmesini ortadan kaldırır.
• dns-prefetch: Harici bir alan adının DNS çözümlemesini erken yapar; preconnect'in daha hafif versiyonudur.
• preload: Sayfada kesinlikle kullanılacak kritik bir kaynağı (LCP görseli, ana font) yüksek öncelikle erken indirir.
• prefetch: Bir sonraki sayfada gerekecek kaynağı boş zamanda önceden indirir; gezinmeyi hızlandırır.

LCP görselini ön yüklemek ve harici font sunucusuna erken bağlanmak, en sık karşılaşılan iki kazanç noktasıdır. Bu ipuçları sayfanın head bölümüne eklenir:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="preload" as="image" href="/kapak.webp" fetchpriority="high" />

Buradaki fetchpriority="high" özelliği, tarayıcıya bu görselin diğer kaynaklardan daha öncelikli indirilmesi gerektiğini açıkça söyler; LCP öğesi için oldukça etkilidir. Next.js'te next/font ve next/image kullanıldığında bu ipuçlarının çoğu otomatik olarak eklenir; manuel ekleme ise daha özel senaryolarda devreye girer.

Gerçek Bir Vaka: Önce ve Sonra

Soyut tavsiyeler yerine somut bir tabloya bakmak, optimizasyonun etkisini en net biçimde gösterir. Aşağıdaki örnek, tipik bir kurumsal e-ticaret sitesinde uygulanan optimizasyonların öncesi ve sonrasını özetler. Değerler temsilidir, ancak sahada karşılaştığımız iyileştirme aralıklarını yansıtır:

Metrik	Optimizasyon Öncesi	Optimizasyon Sonrası	Hedef
LCP	4,8 saniye	2,1 saniye	2,5 saniye altı
INP	410 ms	150 ms	200 ms altı
CLS	0,28	0,04	0,1 altı
Lighthouse Performans	42	94	90 üstü
Hemen çıkma oranı	yüzde 61	yüzde 43	düşük

Bu sonuçlara ulaşmak için yapılan başlıca müdahaleler şunlardı: kapak görseli WebP formatına çevrilip önceliklendirildi ve boyutu doğru ayarlandı; render'ı engelleyen üçüncü taraf scriptler ertelendi; kullanılmayan JavaScript kaldırılarak paket boyutu küçültüldü; tüm görsellere ve reklam alanlarına sabit boyut verildi; fontlar yerel sunucudan ve swap stratejisiyle yüklendi. Görüldüğü gibi, her metrik tek bir sihirli dokunuşla değil; birbirini tamamlayan birkaç doğru kararla iyileştirildi.

Bu tablonun en dikkat çekici satırı hemen çıkma oranıdır. Performans iyileştirmesi yalnızca teknik bir rozet değil; doğrudan kullanıcı davranışını ve dolayısıyla geliri etkileyen bir yatırımdır.

Performans Bütçesi (Performance Budget) Belirlemek

Bir siteyi bir kez hızlandırmak yetmez; o hızı korumak gerekir. Çünkü zamanla yeni özellikler, yeni scriptler ve yeni görseller eklenir ve site fark ettirmeden yeniden yavaşlar. Bu sessiz bozulmayı önlemenin yolu, bir performans bütçesi belirlemektir. Performans bütçesi, ekibin asla aşmamayı taahhüt ettiği üst sınırlardır.

Bir performans bütçesi tipik olarak şu eşikleri içerir: toplam JavaScript boyutu için bir tavan, sayfa başına maksimum ağırlık, LCP/INP/CLS için hedef değerler ve üçüncü taraf script sayısı sınırı. Bu eşikler belirlendikten sonra, her yeni özellik geliştirilirken kontrol edilmelidir. İdeal olan, bu kontrolü otomatikleştirmektir; sürekli entegrasyon (CI) hattına eklenen bir performans testi, bütçeyi aşan bir değişikliği daha yayına çıkmadan yakalar.

Bu disiplin, performansı tek seferlik bir proje olmaktan çıkarıp sürekli bir kültüre dönüştürür. Düzenli ölçüm, otomatik kontrol ve net sınırlar bir araya geldiğinde, site büyürken bile hızlı kalır. Bu kültürün kurulması ve sürdürülmesi, sağlam bir geliştirme ve dağıtım sürecini gerektirir; bu da performansı baştan tasarımın parçası yapan profesyonel bir yaklaşımın neden değerli olduğunu bir kez daha gösterir.

Performans ve SEO İlişkisi

Core Web Vitals'ı iyileştirmenin getirisi yalnızca daha mutlu kullanıcılarla sınırlı değildir; doğrudan arama motoru görünürlüğüne yansır. Google, sayfa deneyimini bir sıralama sinyali olarak kullanır ve eşit kalitede iki içerik arasından daha iyi performans gösteren sayfayı tercih etme eğilimindedir. Yani teknik performans, içerik kalitesini destekleyen bir çarpan görevi görür.

Bunun ötesinde, hızlı bir site tarama bütçesini (crawl budget) daha verimli kullanır, daha düşük hemen çıkma oranı üretir ve daha yüksek dönüşüm sağlar; bunların hepsi dolaylı olarak SEO'yu güçlendirir. Performans optimizasyonunu izole bir teknik görev olarak değil, bütünsel bir SEO ve dijital pazarlama stratejisinin ayrılmaz parçası olarak ele almak en doğru yaklaşımdır. Konuyu daha geniş bir çerçevede ele almak için SEO dostu web sitesi nasıl yapılır yazımız iyi bir tamamlayıcıdır.

Performansa yatırımın maliyet ve geri dönüş boyutunu merak ediyorsanız, web sitesi yaptırma maliyeti 2026 yazımız bütçe planlaması için faydalı bir referanstır.

Sıkça Sorulan Sorular

Core Web Vitals değerlerim kötüyse Google sıralamamı düşürür mü?

Core Web Vitals bir sıralama sinyalidir, ancak tek başına belirleyici değildir. İçerik kalitesi ve alaka düzeyi hâlâ en güçlü etkenlerdir. Bununla birlikte, içeriği benzer iki sayfa arasından Google daha iyi deneyim sunanı tercih eder. Yani kötü CWV doğrudan cezalandırma getirmese de, sizi rekabette geri bırakır. İyi değerler ise dönüşüm ve kullanıcı memnuniyeti üzerinden zaten kazandırır.

Lighthouse'da yüksek puan aldım ama Search Console düşük gösteriyor, neden?

Bu, laboratuvar verisi ile saha verisi farkından kaynaklanır. Lighthouse sabit, kontrollü bir ortamda simülasyon yapar; Search Console ise gerçek kullanıcılarınızın son 28 günlük deneyimini, 75. yüzdelik dilim üzerinden raporlar. Gerçek kullanıcı cihazları ve ağ koşulları genellikle simülasyondan daha zorludur. Bu yüzden gerçek başarıyı her zaman saha verisiyle ölçün.

INP ile eski FID metriği arasındaki fark nedir?

FID yalnızca kullanıcının sayfadaki ilk etkileşiminin gecikmesini ölçüyordu ve genellikle olduğundan iyimser sonuçlar veriyordu. INP ise sayfa ömrü boyunca yapılan tüm etkileşimleri değerlendirir ve gerçek tepkiselliği çok daha doğru yansıtır. Mart 2024'ten itibaren INP, FID'nin yerini resmi Core Web Vitals metriği olarak aldı. Hedef değer 200 milisaniyenin altıdır.

Core Web Vitals'ı iyileştirmek ne kadar sürer?

Bu, mevcut durumun ne kadar kötü olduğuna ve sitenin mimarisine bağlıdır. Görsel optimizasyonu ve font düzeltmeleri gibi bazı iyileştirmeler günler içinde sonuç verebilir. Ancak saha verisi son 28 günü esas aldığı için, yaptığınız iyileştirmelerin Search Console'a tam yansıması birkaç hafta sürer. Yapısal sorunlar varsa, kapsamlı bir yeniden tasarım gerekebilir.

Mobil ve masaüstü için ayrı mı optimize etmeliyim?

Google, mobil ve masaüstü Core Web Vitals değerlerini ayrı raporlar ve mobil deneyim öncelikli indeksleme nedeniyle özellikle önemlidir. Türkiye'de trafiğin büyük kısmı mobil olduğundan, optimizasyonu daima mobil ve orta seviye cihaz koşullarını esas alarak yapmak en güvenli yaklaşımdır. Mobilde iyi olan bir site, masaüstünde zaten büyük olasılıkla iyi olacaktır.

Sonuç

Core Web Vitals, web performansını "iyi his" düzeyinden çıkarıp ölçülebilir, yönetilebilir ve iyileştirilebilir bir disipline dönüştürür. LCP ile yükleme hızını 2,5 saniyenin altına, INP ile etkileşim tepkiselliğini 200 milisaniyenin altına ve CLS ile görsel kaymayı 0,1'in altına çektiğinizde; hem kullanıcılarınız daha iyi bir deneyim yaşar hem de arama motorları sitenizi ödüllendirir. Bu metrikler birbirinden bağımsız değildir; çoğu zaman aynı temel iyi pratikler üçünü birden yukarı çeker.

En önemli ilke, performansı sonradan eklenecek bir yama değil, tasarımın ve geliştirmenin baştan parçası yapmaktır. Görsel ve font optimizasyonu, kod bölme, sunucu bileşenleri ve doğru altyapı kararları bir araya geldiğinde, hızlı bir site istisna değil varsayılan hale gelir. Düzenli ölçüm ve sürekli iyileştirme alışkanlığı ise bu kazanımı kalıcı kılar.

İstanbul merkezli ekibimizle, Next.js ve modern web teknolojileriyle yüksek performanslı, Core Web Vitals hedeflerini karşılayan siteler geliştiriyoruz; mevcut sitenizin performans denetimini yapıp somut bir iyileştirme yol haritası da çıkarabiliriz. Hizmetlerimiz 10.000 TL'den başlayan fiyatlarla sunulur ve ihtiyacınızı anlamak için ücretsiz keşif görüşmesi sağlıyoruz. Sitenizin hızını ölçülebilir biçimde artırmak için bugün bizimle iletişime geçin.