Core Web Vitals İnfazı: FID Gitti, INP Geldi! LCP ve CLS'i Next.js ile Nasıl Çözeriz?

Dijital dünyada hız, uzun yıllar boyunca "Sayfa ne kadar sürede açıldı?" (Page Load Time) gibi son derece sığ ve yanıltıcı bir metrikle ölçüldü. Arama motorları ve kullanıcılar için bir sayfanın sadece beyaz ekrandan çıkıp görünür olması yeterli değildi.

Google, bu kaosu bitirmek ve "Gerçek Kullanıcı Deneyimi (UX)"ni matematiksel olarak ölçebilmek için 2020 yılında Core Web Vitals (Önemli Web Verileri) inisiyatifini duyurdu. Yıllar içinde bu metrikler gelişti, bazıları emekliye ayrıldı ve 2026 itibarıyla oyunun kuralları yepyeni bir seviyeye ulaştı.

Özellikle Mart 2024'te, eski ve işlevsiz FID (First Input Delay) metriğinin yerini INP (Interaction to Next Paint) metriğinin almasıyla, milyonlarca e-ticaret ve B2B sitesi sıralamalarında kan banyosu (Rank Drop) yaşadı.

Bu büyük ölçekli teknik rehberde; yeni nesil Core Web Vitals metriklerini, neden çöktüklerini ve bu çöküşü React/Next.js mimarilerinde (Frontend Engineering) nasıl onaracağımızı derinlemesine inceleyeceğiz.

---

1. Yeni Kral: INP (Interaction to Next Paint) Nedir ve Neden Hayatımızı Zindan Etti?

Eski metrik olan FID (First Input Delay), kullanıcının bir butona tıkladığı an ile tarayıcının o tıklamayı "işlemeye başladığı" (Processing start) an arasındaki gecikmeyi ölçüyordu. Ancak bu, olayın sadece giriş kapısıydı. Kullanıcı butona basıyor, tarayıcı 10 milisaniyede bunu anlıyordu (Optimize edilmiş FID Skoru!) ama arka plandaki o büyük ölçekli JavaScript fonksiyonunun çalışıp ekranı değiştirmesi (Next Paint) 4 saniye sürüyordu. Kullanıcı ekrana boş boş bakıp "Tıklamadı galiba" diyerek 5 kez daha butona basıyordu (Rage Click).

INP (Interaction to Next Paint) ise hikayenin tamamını ölçer. Kullanıcının klavye, fare veya dokunmatik ekranla sayfada yaptığı tüm etkileşimleri (Tıklama, tuşa basma) izler. Ve en önemlisi; tıklama anından, ekranda o tıklamanın görsel sonucunun (Next Paint) çizildiği o nihai ana kadar geçen TOPLAM SÜREYİ hesaplar. Sayfadaki en kötü (en yavaş) etkileşimi alır ve sizin INP skorunuz yapar.

INP Darboğazları Neden Olur ve Nasıl Çözülür?

INP'nin ana düşmanı, "Ana İş Parçacığını" (Main Thread) esir alan büyük ölçekli, hantal JavaScript (JS) dosyalarıdır. Tarayıcı (Browser) single-threaded (Tek şeritli yol) çalışır. Eğer o şeritte dev bir React hesaplaması (Hydration veya VDOM diffing) yapılıyorsa, kullanıcının o sırada attığı "Sepete Ekle" tıklaması yolda sıkışır, geçemez.

Mühendislik Çözümleri (INP Optimizasyonu):

1. Görevi Parçalama (Yielding to Main Thread): Uzun süren (Long Task - 50ms'den uzun süren) JS görevlerinizi parçalamalısınız. setTimeout veya modern tarayıcılarda scheduler.yield() API'sini kullanarak uzun döngülerinizi (Loop) küçük parçalara bölün. Böylece tarayıcı her parça arasında nefes alır ve kullanıcının tıklamasını aradan geçirir.
2. Next.js ve React Server Components (RSC): Yukarıdaki React kaosundan kurtulmanın en kesin yolu budur. Madem tarayıcının Main Thread'i tıkanıyor, o zaman hesaplamaları tarayıcıda yapmayalım! React Server Components sayesinde JS mantığını, API çağrılarını ve state (durum) değişikliklerini Vercel/Node.js sunucusunda halleder, tarayıcıya sadece saf, tıklamaya anında hazır HTML (ve minimum JS) göndeririz.
3. Third-Party (Üçüncü Parti) Kirliliği: Sitenizdeki Google Tag Manager, Hotjar, Facebook Pixel, Intercom gibi pazarlama araçları (Scriptler) INP'nin katilleridir. Bunları ana iplikten kurtarmak için Partytown kütüphanesini kullanın. Partytown, bu 3. parti scriptleri Web Workers (Arka plan iş parçacıkları) içine taşır ve Main Thread'i %100 boşaltır.

---

2. LCP (Largest Contentful Paint) - En Büyük Zayıflık

LCP, ekranın ilk açılışındaki (Viewport) en büyük görünür öğenin (Bu genellikle dev bir Hero resmi (Banner), bir ürün görseli veya dev bir H1 başlığıdır) ekranda tamamen çizilmesi (Render edilmesi) için geçen süreyi ölçer.

Google'ın istediği LCP süresi: 2.5 Saniyenin Altıdır.

E-ticaret siteleri "Güzel görünsün" diye anasayfanın en tepesine 5 MB'lık, 4K çözünürlüğünde kayan bir slider (Carousel) koyduklarında LCP skorları anında 8 saniyeye fırlar.

LCP Nasıl 1 Saniyenin Altına İndirilir? (Next.js Optimizasyonu)

• LCP Öğesini Bulmak ve Asla Tembel Yüklememek (No Lazy-load): Tarayıcı konsolunu açın (Performance tab), LCP öğenizi tespit edin (Örn: Anasayfa Bannerı). Yazılımcıların en büyük hatası, sitenin hızlanması için sayfadaki tüm görsellere (LCP öğesi dahil) loading="lazy" özelliğini eklemeleridir. LCP öğesi ASLA lazy-load (tembel) yüklenmez! Aksine, fetchpriority="high" ve <link rel="preload"> etiketleri kullanılarak tarayıcıya "Her şeyi bırak, önce bu resmi indir" emri verilmelidir.
• Next/Image Component Optimizasyonu: Next.js kullanıyorsanız, <img> etiketi yerine <Image> bileşenini kullanın. Bu bileşen, resimleri otomatik olarak kullanıcının cihaz ekranına göre boyutlandırır (Responsive), modern ve %70 daha hafif olan WebP/AVIF formatlarına çevirir (On-demand) ve CDN üzerinden sunar.
• TTFB (Time to First Byte) İyileştirmesi: LCP'nin en büyük parçası, sunucunun yanıt verme süresidir (TTFB). Veritabanınız hantalsa, resminiz ne kadar küçük olursa olsun LCP yüksek çıkacaktır. TTFB'yi düşürmek için SSR (Server-Side Rendering) yerine SSG (Static Site Generation) veya ISR (Incremental Static Regeneration) mimarilerini kullanın ve tüm sayfaları Edge/Cloudflare CDN'den (Cache) sunun.

---

3. CLS (Cumulative Layout Shift) - Görsel Kayma Sistem darboğazıu

CLS, sayfa yüklenirken ekranın aniden ne kadar kaydığını (zıpladığını) hesaplayan bir "Kararlılık" (Stability) metriğidir.

Hepimiz yaşamışızdır: Tam haberdeki "İptal" butonuna tıklayacakken, sayfanın tepesinden aniden dev bir reklam banner'ı veya son dakika çubuğu yüklenir, sayfa aşağı kayar ve siz yanlışlıkla "Onayla" veya bir Reklam butonuna tıklarsınız. Bu, kusursuz bir kullanıcı düşmanı tasarımdır ve Google (Chrome deneyimleri sayesinde) bunu affetmez. İdeal CLS skoru 0.1'in altında olmalıdır.

graph LR
    A[Kullanıcı Butona Tıklayacak] --> B(Yukarıdan 500px Reklam Yüklenir)
    B --> C[Sayfa Aşağı Kayar - CLS Skoru Fırlar]
    C --> D{Kullanıcı Yanlış Yere Tıklar}
    D --> E(Kötü UX = Google Sıralama Kaybı)
    
    style C fill:#ff9999,stroke:#333

CLS Neden Olur ve Kökten Nasıl Çözülür?

1. Görsellerde Boyut Eksikliği: En yaygın CLS hatasıdır. <img src="gorsel.jpg" alt="Ürün"> kodunda width (genişlik) ve height (yükseklik) değerleri belirtilmemiştir. Tarayıcı, görselin boyutunu dosya inene kadar bilemez. Görsel inince aniden sayfada kendine bir yer (Kutu) açar ve tüm metinleri aşağı iter. Çözüm: Her <img> etiketine mutlaka width ve height (Veya CSS Aspect-Ratio) değerlerini girin. Next.js <Image> bileşeni bu boyutları zorunlu kılarak CLS hatası yapmanızı (By design) engeller.
2. FOUT (Flash of Unstyled Text) / Özel Fontlar: Şirketiniz, sitenizde özel bir web fontu (Örn: Montserrat) kullanıyor. Sayfa açıldığında tarayıcı fontu indirmeden önce metni varsayılan fontla (Times New Roman) çizer. Saniyeler sonra Montserrat fontu inip uygulandığında, iki fontun harf genişlikleri (Line-height/Tracking) farklı olduğu için paragraflar aniden kısalır veya uzar, sayfa kayar. Çözüm: CSS'te font tanımına font-display: optional veya swap eklerken, aynı anda @font-face içinde size-adjust ve metrik override ayarlarını (Next.js next/font modülü bunu otomatik yapar) kullanarak yedek fontun boyutlarını asıl fonta eşitleyin.
3. Dinamik Reklam ve Bildirim Barları (CSR Injections): İstemci tarafında (Client-side) JavaScript ile sonradan (API'den veri gelince) ekrana basılan Promosyon barları veya yorum kutuları CLS'nin baş mimarlarıdır. Çözüm: API'den veri gelecek olan kutunun etrafına CSS ile bir min-height (Minimum Yükseklik) iskeleti (Skeleton UI) oluşturun. Veri gelse de gelmese de o kutunun sayfada kaplayacağı alan en başından rezerve edilsin. Böylece içerik dolduğunda etrafındaki öğeler milimetre bile oynamaz.

---

Sonuç: Lab Verisi Değil, Field (Tarla) Verisi Önemlidir

Geliştiricilerin düştüğü en büyük yanılgı, Google Chrome'da F12'ye basıp Lighthouse (Lighthouse) raporunda 100/100 yeşil skoru görünce her şeyin kusursuz olduğunu sanmaktır.

Lighthouse skoru bir Lab Data'dır (Laboratuvar Verisi). Senin 64 GB RAM'li, M3 işlemcili Macbook Pro'nda ve fiber internetinde her site zaten 100/100 alır.

Oysa Google, Core Web Vitals metriklerini ölçerken (CrUX Report - Chrome User Experience), senin sitene giren ve elinde 5 yıllık, çatlak ekranlı ve 3G hızında interneti olan ortalama bir kullanıcının yaşadığı gerçek deneyimi, yani Field Data (Alan/Tarla Verisini) temel alır. O yüzden SEO'da ve Core Web Vitals'ta mühendislik yaparken kodunuzu her zaman en kötü senaryoya (Slow 3G, CPU Throttling x6) göre test etmeli ve optimize etmelisiniz.

---

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Teknik SEO topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

• JSON-LD ve Microdata Karşılaştırması: Google Neden JSON-LD Öneriyor?
• Büyük E-Ticaret Siteleri İçin Sitemap Optimizasyonu
• Twitter Card Validator Hataları ve Çözümleri: Görseller Neden Çıkmıyor?

🧠 Semantic Entities (Terimler & Senaryolar)

• Kavram: Canonical Tag (Rel=Canonical)
• Kavram: RAG (Retrieval-Augmented Generation)
• Uygulama: GA4 Verilerini Temiz Tutmak: UTM Takibi

Semantic Yönerge: Bu sayfa Core Web Vitals İnfazı: FID Gitti, INP Geldi! LCP ve CLS'i Next.js ile Nasıl Çözeriz? konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.