FCP (First Contentful Paint) Nedir? Nasıl İyileştirilir?

Bir bağlantıya tıkladıktan sonra ekranın beyaz kaldığı her saniye, kullanıcının aklından aynı soru geçer: “Açılıyor mu, yoksa bir sorun mu var?” First Contentful Paint (FCP), bu belirsizliğin bittiği anı ölçer: sayfadan ilk anlamlı içeriğin, yani bir metnin, görselin veya grafiğin ekrana çizildiği anı.

FCP, yüklenme deneyiminin başlangıcını temsil eder. Ana içeriğin geldiği anı ölçen LCP ile birlikte okunduğunda, sayfanın hem ne kadar çabuk tepki verdiğini hem de asıl içeriği ne kadar hızlı getirdiğini gösterir.

FCP neyi ölçer?

FCP, kullanıcının sayfaya gitmek için gezinmeyi başlattığı andan, sayfanın içeriğinden herhangi bir parçanın ilk kez ekrana çizildiği ana kadar geçen süredir. Tarayıcı açısından “içerik” sayılanlar şunlardır:

1. Metin (yazı tipi henüz yüklenmemiş olsa bile görünür biçimde çizilmiş metin)
2. Görseller (CSS arka plan görselleri dahil)
3. Beyaz olmayan <canvas> öğeleri
4. SVG öğeleri

Sayfanın arka plan renginin değişmesi veya boş bir kutunun çizilmesi FCP sayılmaz; bunlar “ilk boyama” (First Paint) olarak ayrıca ölçülür. İframe içindeki içerikler de ana sayfanın FCP’sine dahil edilmez.

Görünmez metin FCP’yi geciktirir

FCP’de gözden kaçan önemli bir ayrıntı yazı tipleridir. Özel bir yazı tipi yüklenirken tarayıcı, varsayılan davranışta metni kısa bir süre görünmez çizer. Görünmez metin, içerik sayılmaz. Yazı tipi yavaş geliyorsa sayfada başka içerik olmadığı sürece FCP de bekler. font-display: swap veya optional kullanıldığında metin yedek yazı tipiyle hemen görünür ve FCP gerçekleşir.

FCP eşik değerleri

1. İyi: 1,8 saniye ve altı
2. İyileştirilmeli: 1,8 ile 3 saniye arası
3. Zayıf: 3 saniyenin üzeri

Diğer hız metriklerinde olduğu gibi değerlendirme, gerçek kullanıcı ziyaretlerinin 75. yüzdelik dilimine göre yapılır. Bu eşikler, üzerinde çalıştığımız pek çok Türkçe kaynakta yer almıyor; oysa hedef bilinmeden yapılan optimizasyonun nerede duracağı da bilinemez.

FCP bir Core Web Vitals metriği mi?

Hayır. Core Web Vitals yalnızca üç metrikten oluşur: LCP, INP ve CLS. FCP ise tanı metriği olarak sınıflandırılır; yani doğrudan sayfa deneyimi sinyali olarak kullanılmaz ama LCP sorunlarının kaynağını anlamaya yardım eder. Search Console’daki Core Web Vitals raporunda FCP bu yüzden yer almaz.

Buna karşılık Lighthouse performans puanında FCP’nin bir ağırlığı vardır (toplam puanın yaklaşık onda biri). Bu yüzden Lighthouse puanını yükseltmek isteyenler için FCP hâlâ önemlidir; ancak arama görünürlüğü açısından asıl hedef LCP’dir.

FCP ile ilgili metrikler

First Paint (FP): Ekranda herhangi bir pikselin, örneğin arka plan renginin değiştiği ilk an. FCP her zaman FP’ye eşit ya da ondan sonradır.

Largest Contentful Paint (LCP): En büyük içerik öğesinin çizildiği an. FCP ile LCP aynı anda da gerçekleşebilir; sayfanın ilk çizdiği içerik zaten en büyük öğeyse iki değer eşittir.

First Meaningful Paint (FMP): Eskiden kullanılan, “anlamlı” içeriğin ilk çizildiği anı ölçmeye çalışan metrik. Tutarsız sonuçlar ürettiği için Lighthouse’tan kaldırıldı ve yerini LCP aldı. Bugün yazılan rehberlerde FMP’nin güncel bir metrik gibi anlatılması yanıltıcıdır.

Speed Index: Sayfanın görsel olarak ne kadar hızlı dolduğunu ölçen laboratuvar metriği. FCP’den sonraki ilerlemeyi de hesaba katar.

FCP’yi oluşturan zaman dilimleri

FCP’yi iyileştirmenin en verimli yolu, onu iki ana parçaya ayırmaktır:

FCP = İlk bayta kadar geçen süre (TTFB) + İlk bayttan ilk çizime kadar geçen süre

Birinci parça, sunucudan ilk baytın gelmesine kadar geçen süredir: yönlendirmeler, DNS çözümlemesi, bağlantı kurulumu, TLS el sıkışması ve sunucunun sayfayı hazırlaması. Bu kısım tamamen ağ ve sunucu tarafındadır; ayrıntısını TTFB yazımızda anlattık.

İkinci parça, HTML geldikten sonra tarayıcının ilk içeriği çizebilmek için beklediği süredir. Burada belirleyici olan, render engelleyici kaynaklardır: tarayıcının sayfayı çizmeden önce indirip işlemek zorunda olduğu CSS dosyaları ve senkron JavaScript betikleri.

Bu ayrımın pratik değeri büyüktür. TTFB 1,5 saniye olan bir sayfada, ön yüzde ne yapılırsa yapılsın FCP’nin 1,8 saniyenin altına inmesi neredeyse imkânsızdır. Tersine, TTFB 0,3 saniye ama FCP 2,5 saniye ise sorun tamamen tarayıcı tarafındaki engelleyici kaynaklardadır.

FCP’yi geciktiren başlıca sebepler

1. Yavaş sunucu yanıtı

Önbelleksiz dinamik sayfalar, yavaş veritabanı sorguları ve yetersiz sunucu kaynakları TTFB’yi uzatır. FCP’nin tabanını bu süre belirler.

2. Yönlendirme zincirleri

Her yönlendirme, yeni bir istek ve çoğu zaman yeni bir bağlantı demektir. HTTP’den HTTPS’e, oradan www’li adrese, oradan da son adrese giden bir zincir, kullanıcı daha hiçbir şey görmeden yüzlerce milisaniye harcatır. Yönlendirme düzenini URL yönlendirmeleri rehberimizde ele aldık.

3. Render engelleyici CSS

Tarayıcı, <head> içindeki stil dosyalarının tamamı inip işlenmeden sayfayı çizmez; çünkü stilsiz içerik gösterip sonra biçimlendirmek kötü bir deneyim yaratır. Bu doğru bir davranıştır ama büyük ve bölünmemiş CSS dosyaları FCP’yi doğrudan geciktirir. Özellikle bir CSS dosyası içinden @import ile başka bir dosya çağrılıyorsa, ikinci dosya ancak birincisi indikten sonra keşfedilir ve zincir uzar.

4. Senkron JavaScript

<head> içinde async veya defer niteliği olmayan betikler, HTML ayrıştırmasını durdurur. Tarayıcı betiği indirip çalıştırana kadar sayfanın geri kalanını işlemez. Etiket yöneticisi, A/B test aracı ve sohbet balonu gibi üçüncü taraf betiklerinin senkron eklenmesi, FCP’nin en sık gözden kaçan sebeplerindendir.

5. Yazı tipi yükleme davranışı

Yukarıda anlattığımız görünmez metin davranışı, sayfanın tek içeriği metin olduğunda FCP’yi yazı tipi indirme süresi kadar geciktirir.

6. İstemci tarafında oluşturma

İçeriğin tamamının JavaScript ile oluşturulduğu sayfalarda sunucudan gelen HTML neredeyse boştur. İlk içerik ancak çatı betiği indirilip çalıştıktan sonra çizilir. Bu yapılarda FCP, betiğin boyutuna ve cihazın işlemci gücüne doğrudan bağlıdır; orta seviye telefonlarda saniyeler sürebilir.

7. Büyük HTML ve DOM

Çok büyük HTML belgeleri hem indirme hem ayrıştırma süresini uzatır. Satır içine gömülmüş büyük görseller (base64), şişkin satır içi stiller ve binlerce öğeden oluşan menüler bu soruna yol açar.

FCP nasıl iyileştirilir?

Sunucu tarafı

1. Sayfa önbelleği kurun. Her istekte yeniden oluşturulan sayfalar yerine hazır HTML sunmak, TTFB’yi en hızlı düşüren yöntemdir.
2. HTML’i CDN üzerinden önbelleğe alın. Kullanıcıya yakın bir noktadan gelen HTML, ağ gecikmesini de azaltır. Gecikmenin fiziksel boyutunu RTT yazımızda anlattık.
3. Yönlendirmeleri kaldırın. İç bağlantılar ve reklam adresleri doğrudan son adresi göstermelidir.
4. Sıkıştırmayı açın. Metin dosyaları için Brotli veya gzip sıkıştırma, indirme süresini kısaltır.
5. HTML’i akış hâlinde gönderin. Sunucu, sayfanın başını hazırlar hazırlamaz göndermeye başlarsa tarayıcı CSS’i ve kritik kaynakları daha erken keşfeder.
6. 103 Early Hints kullanın. Sunucu sayfayı hazırlarken tarayıcıya kritik kaynakların listesini önceden gönderebilir; tarayıcı bu sürede CSS ve yazı tiplerini indirmeye başlar.

Tarayıcı tarafı

1. Kritik CSS’i satır içine alın. İlk ekranı çizmek için gereken stilleri doğrudan HTML’e gömün, geri kalan stil dosyalarını çizimi engellemeyecek biçimde yükleyin.
2. Kullanılmayan CSS’i temizleyin. Çok amaçlı temalar ve bileşen kütüphaneleri, sayfanın kullanmadığı binlerce satır stil getirir.
3. @import kullanmayın. Stil dosyalarını HTML’de doğrudan bağlayın ki tarayıcı hepsini paralel keşfetsin.
4. Betikleri erteleyin. İlk çizim için gerekmeyen tüm betiklere defer veya async ekleyin; üçüncü taraf betiklerini sayfa çizildikten sonra yükleyin.
5. Yazı tiplerini akıllıca yükleyin. font-display: swap veya optional kullanın, kritik yazı tiplerini önceden yükleyin, yalnızca gerçekten kullanılan ağırlıkları indirin.
6. Bağlantıları önceden kurun. Kritik kaynaklar başka bir alan adından geliyorsa preconnect ile DNS, TCP ve TLS adımlarını erkenden tamamlayın.
7. İlk ekran içeriğini sunucuda oluşturun. Tek sayfa uygulamalarında sunucu tarafında oluşturma veya statik ön oluşturma, FCP’yi en çok iyileştiren adımdır.

FCP nasıl ölçülür?

PageSpeed Insights

Üst bölümde gerçek kullanıcı verisi (Chrome User Experience Report), alt bölümde Lighthouse laboratuvar ölçümü yer alır. FCP her iki bölümde de gösterilir. Laboratuvar bölümündeki “render engelleyici kaynakları kaldırın” tanılaması, FCP’yi geciktiren dosyaları ve tahmini kazancı listeler.

Chrome geliştirici araçları

Performans panelinde alınan kayıtta FCP zaman çizelgesinde işaretlenir. Ağ panelindeki şelale görünümü, FCP’den önce hangi dosyaların indirildiğini ve hangilerinin birbirini beklediğini gösterir. Araçların ayrıntılı kullanımı için geliştirici araçları rehberimize bakabilirsiniz.

Paint Timing API ve gerçek kullanıcı ölçümü

Tarayıcılar FCP değerini Paint Timing API üzerinden sunar. PerformanceObserver ile paint türündeki kayıtlar dinlenerek her ziyaretin FCP’si toplanabilir. Pratikte bunun için Google’ın açık kaynaklı web-vitals kütüphanesini kullanmak daha güvenlidir; çünkü kütüphane şu özel durumları doğru ele alır:

1. Arka planda açılan sekmeler: Kullanıcı sayfayı arka plan sekmesinde açtıysa çizim ertelenir; bu ziyaretlerin FCP’si yanıltıcı olduğu için dikkate alınmaz.
2. Geri-ileri önbelleği: Sayfa önbellekten geri getirildiğinde FCP, geri getirme anından itibaren ölçülür.
3. Önceden oluşturulan sayfalar: Tarayıcı sayfayı kullanıcı tıklamadan önce hazırladıysa ölçüm, sayfanın gerçekten gösterildiği andan başlatılır.

Saha verisi ile laboratuvar verisi

Lighthouse, sayfayı yavaş bir mobil bağlantı ve yavaşlatılmış işlemci simülasyonuyla bir kez yükler. Gerçek kullanıcılar ise çok farklı koşullarda gelir: bazıları hızlı fiber bağlantıda, bazıları kalabalık bir mobil hücrede. Bu yüzden iki değerin farklı olması olağandır. Laboratuvar, sorunu bulmak ve düzeltmeyi test etmek; saha verisi ise gerçek deneyimi görmek içindir. Bu ayrımın genel mantığını site hızı yazımızda ele aldık.

Tarayıcı farklılıkları

Paint Timing API, günümüzde yaygın tarayıcıların büyük bölümünde desteklenir. Ancak Chrome User Experience Report yalnızca Chrome kullanıcılarından veri toplar. iPhone kullanıcılarının ağırlıklı olduğu kitlelerde bu veri, kitlenizin bir kısmını hiç göstermeyebilir. Bu yüzden özellikle iOS trafiği yüksek sitelerde kendi gerçek kullanıcı ölçümünüzü kurmak, tabloyu tamamlamanın tek yoludur.

Tarayıcıların “ilk içerik” tanımında da küçük farklar olabilir; örneğin görünmez metnin veya bazı SVG türlerinin nasıl sayıldığı. Bu nedenle farklı tarayıcılardan gelen FCP değerlerini birbirleriyle değil, her tarayıcıyı kendi geçmişiyle karşılaştırmak daha sağlıklıdır.

FCP ile LCP arasındaki mesafe ne anlatır?

İki metriği birlikte okumak, sorunun yerini hızlıca gösterir:

1. FCP yüksek, LCP yüksek: Sorun büyük olasılıkla sunucu tarafındadır (TTFB) veya render engelleyici kaynaklar her şeyi bekletiyordur.
2. FCP düşük, LCP yüksek: Sayfa hızlı başlıyor ama ana içerik geç geliyor. Genellikle LCP görseli geç keşfediliyor, tembel yükleniyor veya JavaScript ile sonradan ekleniyordur.
3. FCP ve LCP eşit ve düşük: İlk çizilen içerik aynı zamanda ana içeriktir; sayfa sağlıklıdır.

İkinci durum uygulamada en sık gördüğümüz tablodur ve çözümü FCP’de değil LCP tarafındadır; ayrıntısını LCP yazımızda anlattık.

Sık yapılan hatalar

1. FCP’yi Core Web Vitals metriği sanmak. Tanı metriğidir; sıralama sinyali olarak kullanılan LCP’dir.
2. TTFB’ye bakmadan ön yüz optimizasyonu yapmak. Yavaş sunucu, FCP’nin tabanını belirler.
3. Tüm CSS’i satır içine gömmek. Yalnızca kritik stiller gömülmeli; aksi hâlde HTML şişer ve önbellekten yararlanılamaz.
4. Üçüncü taraf betiklerini <head>’e senkron eklemek. Etiket yöneticisi bile asenkron yüklenmelidir.
5. FMP gibi kaldırılmış metriklere göre hedef koymak.
6. Yalnızca masaüstü ölçümüne bakmak. FCP sorunları en belirgin biçimde mobilde görülür.

Kritik istek zinciri: FCP’nin gizli düşmanı

Tarayıcı bir sayfayı çizebilmek için bazı dosyaları sırayla indirmek zorunda kalabilir. HTML bir CSS dosyasını çağırır, o CSS dosyası bir yazı tipini ve başka bir CSS dosyasını çağırır, o yazı tipi de ancak CSS işlendikten sonra keşfedilir. Bu sıralı bağımlılığa kritik istek zinciri denir. Zincirin her halkası en az bir ağ gidiş-dönüş süresi ekler; mobil ağda her halka 100-300 milisaniye anlamına gelebilir.

Lighthouse’un tanılama bölümü bu zinciri görselleştirir. Amaç zinciri mümkün olduğunca kısaltmak ve yatay hâle getirmektir: kritik dosyaların hepsinin HTML’den doğrudan keşfedilmesi ve paralel indirilmesi. Bunun için @import kullanımından kaçınmak, kritik yazı tiplerini preload ile HTML’de bildirmek ve üçüncü taraf stil dosyalarını kendi sunucunuzdan sunmak işe yarar.

Preload, prefetch ve preconnect arasındaki fark

Bu üç kaynak ipucu sıkça birbirine karıştırılır; yanlış kullanıldığında FCP’yi iyileştirmek yerine kötüleştirir.

Preload, “bu dosyayı bu sayfada kesinlikle kullanacağım, hemen ve yüksek öncelikle indir” demektir. Tarayıcının geç keşfedeceği kritik kaynaklar (CSS içinden çağrılan yazı tipi, CSS arka planındaki ana görsel) için kullanılır. Gereğinden fazla preload, bant genişliğini gerçekten kritik dosyalarla paylaştırır ve ters etki yapar.

Prefetch, “bu dosyayı büyük olasılıkla bir sonraki sayfada kullanacağım, boşta kalınca düşük öncelikle indir” demektir. Mevcut sayfanın FCP’sine katkısı yoktur; sonraki gezinmeyi hızlandırır.

Preconnect, “bu alan adından birazdan dosya isteyeceğim, bağlantıyı şimdiden kur” demektir. DNS çözümlemesi, TCP bağlantısı ve TLS el sıkışmasını önceden tamamlar. Kritik kaynaklar ayrı bir alan adından geliyorsa (yazı tipi sağlayıcısı, görsel CDN’i) FCP’yi yüzlerce milisaniye iyileştirebilir. Ancak yalnızca gerçekten kullanılacak iki-üç alan adı için eklenmelidir; kullanılmayan bağlantılar kaynak israfıdır.

CDN, protokol ve sıkıştırmanın rolü

İçerik dağıtım ağı (CDN), dosyaları kullanıcıya coğrafi olarak yakın sunuculardan verir. FCP açısından en büyük kazanç, yalnızca görsel ve betiklerin değil HTML’in de CDN kenar sunucularında önbelleğe alınmasıyla elde edilir; çünkü FCP’nin tabanı HTML’in ilk baytının ne zaman geldiğidir.

Protokol tarafında HTTP/2, tek bağlantı üzerinden birden fazla dosyanın paralel indirilmesini sağlar; HTTP/1.1 döneminin dosya birleştirme gibi eski tekniklerine çoğu zaman gerek bırakmaz. HTTP/3 ise bağlantı kurulumunu kısaltır ve kayıplı mobil ağlarda daha dayanıklıdır. Bağlantı kurulumunun FCP’ye maliyetini RTT yazımızda ayrıntılı anlattık.

Sıkıştırma tarafında metin dosyaları (HTML, CSS, JavaScript) için Brotli, gzip’e göre genellikle daha küçük dosya üretir. Görseller ve yazı tipleri zaten sıkıştırılmış biçimler olduğu için bunlara ayrıca sıkıştırma uygulamak anlamlı değildir.

WordPress sitelerinde FCP

WordPress sitelerinde FCP’yi geciktiren en yaygın kaynaklar şunlardır: tema ve eklentilerin her sayfada yüklediği stil dosyaları, <head> içine senkron eklenen betikler, harici yazı tipi servisleri ve önbelleksiz dinamik sayfa üretimi. Sayfa önbelleği eklentisi veya sunucu düzeyinde önbellek kurmak, kullanılmayan eklentileri kaldırmak ve kritik CSS üretimini açmak çoğu sitede FCP’yi belirgin biçimde iyileştirir. Adımların tamamını WordPress hızlandırma rehberimizde sıraladık.

FCP kontrol listesi

1. TTFB 0,8 saniyenin altında mı?
2. Yönlendirme zinciri var mı?
3. Kritik CSS satır içinde, geri kalanı ertelenmiş mi?
4. @import kullanımı kaldırıldı mı?
5. <head> içinde senkron betik kaldı mı?
6. Yazı tiplerinde font-display tanımlı ve kritik yazı tipleri önceden yükleniyor mu?
7. Kritik üçüncü taraf alan adları için preconnect var mı?
8. HTML, CSS ve JavaScript sıkıştırılarak sunuluyor mu?
9. HTML, CDN kenar sunucularında önbelleğe alınıyor mu?
10. FCP ile LCP arasındaki mesafe izleniyor mu?

Algılanan hız: FCP neden kullanıcı için önemli?

Kullanıcı açısından bekleme süresinin nasıl hissedildiği, gerçek süreden çoğu zaman daha önemlidir. Ekranın boş kaldığı iki saniye, içeriğin yavaş yavaş dolduğu iki saniyeden çok daha uzun hissedilir. FCP bu yüzden “algılanan hızın” en güçlü göstergelerinden biridir: sayfa bir şey göstermeye başladığında kullanıcı beklemeye razı olur, hiçbir şey göstermediğinde ise geri tuşuna uzanır.

Bu nedenle bazı tasarım tercihleri FCP’yi iyileştirmek için bilinçli olarak yapılır: sayfanın iskeletini, başlığını ve menüsünü önce göstermek, ağır bölümleri sonra doldurmak. Ancak burada bir denge vardır: FCP’yi erkene çekmek için anlamsız bir yükleme ekranı göstermek, LCP ve kullanıcı deneyimi açısından bir kazanç sağlamaz. Hedef, kullanıcının gerçekten işine yarayan içeriği mümkün olan en erken anda göstermektir.

Özetle

FCP, kullanıcının boş ekrandan kurtulduğu anı ölçer ve 1,8 saniyenin altında kalması hedeflenir. Core Web Vitals metriği değildir ama LCP sorunlarının kaynağını anlamak için vazgeçilmez bir tanı aracıdır. FCP’yi TTFB ve ilk bayttan çizime kadar geçen süre olarak ikiye ayırmak, sorunun sunucuda mı yoksa tarayıcıdaki engelleyici kaynaklarda mı olduğunu hemen gösterir. En büyük kazançlar genellikle sayfa önbelleği, kritik CSS, betiklerin ertelenmesi ve yazı tipi ayarlarından gelir. Teknik SEO çalışmanızın bütününü planlamak için SEO hizmetimizi inceleyebilirsiniz.