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

Bir kullanıcı sayfanızı açtığında ekranda ilk üç saniye boyunca bembeyaz bir alan görüyorsa, sitenizin geri kalanının ne kadar iyi olduğunun bir önemi kalmaz; çoğu ziyaretçi o beyaz ekranı beklemez. FCP (First Contentful Paint), yani ilk içerikli boyama, tam olarak bu beyaz ekranın ne kadar sürdüğünü ölçer: navigasyonun başladığı andan, ekranda ilk metin ya da görselin çizildiği ana kadar geçen süre.

Bu rehberde FCP'nin fiziksel olarak neyi ölçtüğünü, LCP ile arasındaki farkı, hangi kaynakların ilk boyamayı geciktirdiğini ve bunları nasıl tek tek ayıklayacağınızı anlatacağım. FCP'nin güzel yanı, iyileştirilmesi büyük mimari değişiklikler gerektirmemesidir; çoğu sitede birkaç render engelleyici kaynağı düzeltmek saniyeler kazandırır. Kötü yanı ise sebebin hemen hiçbir zaman tek bir şey olmamasıdır, o yüzden sırayla gitmek gerekir.

FCP Tam Olarak Neyi Ölçer#

FCP, tarayıcının ekrana DOM'dan gelen ilk içeriği boyadığı anı işaretler. "İçerik" tanımı kesindir: metin, görsel (arka plan görselleri dâhil), canvas üzerine çizilmiş bir şey ya da bir SVG. Arka plan rengi, kenarlık veya boş bir kutu içerik sayılmaz. Yani sayfanız gri bir arka planla açılıyor ama henüz tek bir harf çizilmediyse FCP saati hâlâ işlemektedir.

Bu tanımın pratikte iki önemli sonucu vardır. Birincisi, FCP kullanıcı için "bir şeyler oluyor" sinyalidir; sayfanın kullanılabilir olduğunu değil, ölmediğini gösterir. İkincisi, FCP'yi geciktiren şeyler neredeyse her zaman ilk boyamadan önce çalışması gereken kaynaklardır: sunucunun cevabı, kritik CSS ve senkron JavaScript. Sayfanın alt kısmındaki dev bir görsel FCP'yi etkilemez, ancak head içindeki 200 KB'lık bir CSS dosyası doğrudan etkiler.

FCP, Core Web Vitals'ın üç ana metriğinden biri değildir ama Google'ın "diğer web vitals" listesinde yer alır ve Lighthouse performans skorunun yaklaşık onda birini oluşturur. Daha da önemlisi, FCP kötüyse LCP de neredeyse kesinlikle kötüdür; çünkü ikisi de aynı ilk aşamayı paylaşır. Metriklerin birbirine nasıl bağlandığını Core Web Vitals rehberinde topluca ele aldım.

Eşik Değerler ve LCP ile Farkı#

FCP için kabul edilen eşik değerler şunlardır:

FCP ile LCP arasındaki farkı bir örnekle netleştirelim. Sayfanız açıldığında önce üst menüdeki metin çizilir; bu an FCP'dir. Ardından ana görsel yüklenip ekranın büyük bölümünü kaplar; bu an LCP'dir. İkisi arasında geçen süre size çok şey söyler: fark küçükse (0,3 sn gibi) yükleme akıcıdır, fark büyükse (2 sn gibi) kullanıcı yarım bir sayfaya bakarak bekliyor demektir. Bu durumda müdahale edilmesi gereken şey LCP kaynağıdır; LCP nasıl iyileştirilir yazısı bu adımı ayrıntılı anlatıyor.

Bir başka kritik ayrım: FCP kötüyse LCP'yi düzeltmek işe yaramaz. Çünkü LCP saati de aynı anda başlar; ilk boyamaya kadar kaybedilen her milisaniye LCP'ye de eklenir. Bu yüzden performans çalışmasına her zaman FCP'den başlanır, sonra LCP'ye geçilir.

FCP'yi Geciktiren Beş Ana Sebep#

Sahada gördüğüm yüksek FCP değerlerinin neredeyse tamamı şu beş başlıktan birine ya da birkaçına dayanır:

1. Yüksek TTFB. Sunucu cevabı 1 saniyede döndürüyorsa FCP hiçbir zaman 1 saniyenin altına inemez. Bu, tavanı belirleyen sabittir.
2. Render engelleyen CSS. Tarayıcı head içindeki her stil dosyasını indirip ayrıştırmadan tek piksel çizmez.
3. Senkron JavaScript. defer ya da async almamış bir script etiketi HTML ayrıştırmasını tamamen durdurur.
4. Yazı tipi beklemesi. Varsayılan font-display davranışında tarayıcı, yazı tipi inene kadar metni görünmez tutabilir; buna FOIT denir.
5. Uzun yönlendirme zinciri. Her 301/302 adımı yeni bir DNS + bağlantı + TTFB turu demektir.

Bu beşinin hangisinin sizde baskın olduğunu tahmin etmeyin; bir waterfall grafiğine bakıp FCP çizgisinin soluna düşen istekleri sayın. Waterfall grafiği nasıl okunur yazısındaki yöntem bu tespiti dakikalar içinde yapmanızı sağlar.

Sunucu Yanıt Süresini Düşürmek#

FCP'nin tavanı TTFB'dir, o yüzden ilk iş burasıdır. Mevcut durumu ölçmek için tarayıcıya bile ihtiyacınız yok:

# 5 kez olcup TTFB dagilimini gor
for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://firmaniz.com/
done

Değerler 600 ms'nin üzerindeyse sırasıyla şunlara bakın: sayfa önbelleği devrede mi, veritabanı sorguları ne kadar sürüyor, PHP-FPM işçi sayısı yeterli mi ve sunucu diski NVMe mi. WordPress kullanıyorsanız tam sayfa önbelleği tek başına TTFB'yi çoğu zaman onda birine indirir; LiteSpeed Cache ya da Nginx FastCGI önbelleği bunun iki yaygın yoludur.

Nginx tarafında mikro önbellek denen basit yapılandırma bile dramatik fark yaratır:

# 1 dakikalik mikro onbellek: dinamik sayfalari bile hizlandirir
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MICRO:100m inactive=10m;

server {
    location ~ \.php$ {
        fastcgi_cache MICRO;
        fastcgi_cache_valid 200 1m;
        fastcgi_cache_use_stale updating error timeout;
        add_header X-Cache-Status $upstream_cache_status;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

X-Cache-Status başlığı sayesinde önbelleğin gerçekten çalışıp çalışmadığını curl -sI ile anında doğrulayabilirsiniz; HIT görüyorsanız iş tamamdır.

Render Engelleyen CSS ve JavaScript'i Ayıklamak#

Tarayıcı, head içindeki her link rel="stylesheet" etiketini indirip işlemeden ekrana hiçbir şey çizmez. Bu davranış kasıtlıdır: stilsiz içerik göstermek daha kötü bir deneyim olurdu. Sizin işiniz, ilk ekranda gerçekten gereken stili küçültmek ve gerisini ertelemektir.

En etkili yöntem kritik CSS'i satır içine almak, kalanını asenkron yüklemektir:

<style>
  body{margin:0;font-family:system-ui,sans-serif;color:#111}
  .ust-bar{height:56px;background:#0f172a}
  .baslik{font-size:2rem;line-height:1.2;margin:24px 16px}
</style>
<link rel="stylesheet" href="/css/tam.css" media="print" onload="this.media='all'">

Buradaki media="print" numarası şudur: tarayıcı yazdırma stilini render engelleyici saymaz, dosya indikten sonra onload ile media değeri all yapılır ve stil devreye girer. JavaScript tarafında ise kural daha basittir; head içindeki hiçbir betik senkron olmamalıdır:

<script src="/js/uygulama.js" defer></script>
<script src="/js/analiz.js" async></script>

defer, betiği indirir ama HTML ayrıştırması bitene kadar çalıştırmaz ve dosya sırasını korur; uygulama kodu için doğru seçim budur. async, indiği anda çalışır ve sırayı korumaz; birbirinden bağımsız analiz betikleri için uygundur. İkisi de FCP'yi engellemez. Ana iş parçacığını meşgul eden betiklerin etkileşim tarafındaki bedeli için TBT metriğine bakabilirsiniz.

Yazı Tipleri ve font-display Davranışı#

Web yazı tipleri FCP'nin en sinsi düşmanıdır, çünkü sorun görünmez: dosya indiriliyordur, ağ hatası yoktur, ama metin ekranda yoktur. Tarayıcının varsayılan davranışı, yazı tipi inene kadar metni gizlemektir (blok süresi). Bu davranışı tek satırla değiştirebilirsiniz:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
  font-weight: 400;
  font-display: swap;
}

font-display: swap tarayıcıya şunu söyler: "yazı tipini bekleme, sistem yazı tipiyle hemen çiz, dosya gelince değiştir." Bu tek değişiklik, yazı tipi kaynaklı FCP gecikmesini pratikte sıfırlar. Karşılığında küçük bir yazı tipi değişimi (FOUT) görürsünüz; bunu azaltmak için yedek yazı tipini metrik olarak yakın seçmek yeterlidir.

Yazı tipi dosyalarının kendisini de hafifletin: yalnızca woff2 sunun, Latin dışındaki karakter kümelerini unicode-range ile ayırın ve Türkçe karakterler için Latin Extended alt kümesini eklemeyi unutmayın. Harici bir yazı tipi servisi kullanıyorsanız preconnect ile bağlantıyı erkenden kurun; aksi hâlde DNS + TLS için 200-300 ms fazladan ödersiniz.

FCP'yi Doğru Ölçmek#

FCP'yi iki farklı kaynaktan ölçebilirsiniz ve ikisi de gereklidir. Laboratuvar ölçümü için Lighthouse'un komut satırı sürümü hızlıdır:

# Sadece performans kategorisi, mobil profil
npx lighthouse https://firmaniz.com/ \
  --only-categories=performance \
  --form-factor=mobile \
  --output=json --output-path=./rapor.json --quiet

# Raporun icinden FCP degerini cek
node -e "const r=require('./rapor.json');console.log(r.audits['first-contentful-paint'].displayValue)"

Gerçek kullanıcı verisi için ise tarayıcıdan doğrudan okuyabilirsiniz. Aşağıdaki kısa kod, gerçek ziyaretçilerin FCP değerini kendi sunucunuza gönderir:

// Gercek kullanicidan FCP olcumu
new PerformanceObserver((list) => {
  for (const entry of list.getEntriesByName("first-contentful-paint")) {
    navigator.sendBeacon("/olcum", JSON.stringify({ fcp: Math.round(entry.startTime) }));
  }
}).observe({ type: "paint", buffered: true });

Laboratuvar ve saha verisi arasındaki farkın neden bu kadar açılabildiğini ve hangisine güvenmeniz gerektiğini CrUX alan verisi ve lab verisi yazısında ayrıntılı ele aldım.

Sık Yapılan Hatalar#

En yaygın hata, FCP'yi tek başına bir eklentiyle çözmeye çalışmaktır. Önbellek eklentileri TTFB'yi düşürür ve bu gerçekten işe yarar; ancak render engelleyen bir tema CSS'ini ya da head içindeki senkron bir betiği ortadan kaldırmazlar. Eklentiyi kurup skoru kontrol etmeden "hallettim" demeyin.

İkinci hata, kritik CSS'i abartmaktır. İlk ekranda görünmeyen her şeyi kritik CSS'e koyarsanız satır içi stil 80 KB'a çıkar ve kazandığınızdan fazlasını kaybedersiniz. Kritik CSS 14 KB civarında kalmalıdır; bu, ilk TCP penceresine sığan yaklaşık boyuttur.

Üçüncü hata, preload'u her şeye uygulamaktır. preload, bir kaynağı öne alır ama bunu diğer kaynakların bant genişliğinden çalarak yapar. On tane preload etiketi koyduğunuzda hiçbiri öncelikli olmaz, sadece hepsi yavaşlar. İki üç kritik kaynakla sınırlı tutun.

Dördüncü hata ise yönlendirme zincirlerini görmezden gelmektir. http://firmaniz.com → https://firmaniz.com → https://www.firmaniz.com şeklinde iki adımlı bir zincir, mobil bağlantıda kolayca 400-600 ms ekler. Kanonik adrese tek adımda gidin:

# Kac yonlendirme var, her adim ne kadar surdu
curl -sIL -o /dev/null -w "Adim sayisi: %{num_redirects}\nToplam: %{time_total}s\n" http://firmaniz.com

Hangi Sırayla Düzeltmek Gerekir#

Elinizde birden fazla sorun varsa hepsine aynı anda saldırmak zaman kaybıdır; kazanç/emek oranı en yüksek olandan başlamak gerekir. Aşağıdaki sıra, onlarca sitede uyguladığım ve neredeyse her seferinde işe yarayan öncelik listesidir:

İlk dört maddenin tamamı bir öğleden sonrada yapılabilir ve çoğu sitede FCP'yi zaten hedef bölgeye çeker. Kritik CSS ayırmayı en sona bıraktım çünkü bakım maliyeti yüksektir: tasarımda her değişiklik yaptığınızda satır içi stili yeniden üretmeniz gerekir. Bu adımı otomatik bir derleme aşamasına bağlamadan elle yapmaya kalkarsanız, birkaç ay sonra sayfanın stilsiz görünmesiyle uğraşırsınız.

Her müdahaleden sonra tek bir değişiklikle ölçüm alın ve sonucu not edin. Aynı anda beş şey değiştirip skoru ölçerseniz, hangisinin işe yaradığını asla öğrenemez ve bir sonraki sitede aynı tahminlerle başlarsınız.

Sıkça Sorulan Sorular#

FCP kaç saniye olmalı#

Google'ın kabul ettiği "iyi" eşik 1,8 saniyedir ve bu değer saha verisinde 75. yüzdelik dilim için geçerlidir. 1,8 ile 3 saniye arası iyileştirme gerektiren bölge, 3 saniye üzeri ise zayıf kabul edilir. Kurumsal bir tanıtım sayfasında 1 saniyenin altına inmek gayet mümkündür; ağır bir uygulama arayüzünde 1,5 saniye civarı gerçekçi bir hedeftir.

FCP ile LCP arasındaki fark nedir#

FCP ekrana çizilen ilk içeriği, LCP ise görünür alandaki en büyük içerik öğesinin çizildiği anı ölçer. FCP genellikle bir menü metni ya da başlıkla gerçekleşir; LCP çoğu sitede ana görsel veya büyük başlık bloğudur. FCP her zaman LCP'den önce gelir ve LCP'nin alt sınırını belirler.

FCP'yi düzeltmek SEO'ya yarar mı#

Doğrudan bir sıralama faktörü olan Core Web Vitals metriği LCP, INP ve CLS'tir; FCP bunların arasında değildir. Ancak FCP'yi düşürmek LCP'yi de düşürür, çünkü ikisi aynı ilk aşamayı paylaşır. Dolayısıyla dolaylı ama gerçek bir etkisi vardır. Ayrıca hemen çıkma oranı gibi davranışsal sinyallerde de olumlu etki görürsünüz.

Render engelleyen kaynakları nasıl bulurum#

En pratik yol Lighthouse raporundaki "Eliminate render-blocking resources" bölümüdür; hangi dosyanın kaç milisaniye engellediğini listeler. Aynı bilgiyi DevTools Network panelinde FCP çizgisinin soluna düşen CSS ve JS isteklerine bakarak da görebilirsiniz. Coverage sekmesi ise indirilen CSS'in ne kadarının gerçekten kullanıldığını gösterir.

font-display swap kullanmak güvenli mi#

Evet, modern tarayıcıların tamamı destekler ve pratikte tek yan etkisi kısa süreli yazı tipi değişimidir. Kurumsal kimlik açısından bu değişim rahatsız ediciyse font-display: optional kullanabilirsiniz; bu durumda yazı tipi çok hızlı inmezse tarayıcı o sayfa için hiç kullanmaz ve değişim yaşanmaz. En kötü seçenek varsayılan davranışta bırakmaktır.

Paylaşımlı hostingde FCP iyileştirilebilir mi#

Evet, çoğu kazanç sunucu tipinden bağımsızdır: render engelleyen kaynakları ayıklamak, font-display eklemek, yönlendirme zincirini kısaltmak ve sıkıştırmayı açmak paylaşımlı pakette de aynı sonucu verir. Sunucu yoğunluğu nedeniyle TTFB'de bir taban oluşabilir; bu tabanın altına inmek gerektiğinde ayrılmış kaynaklı bir plana geçmek gerekir.

Kapanış#

FCP, sitenizin "yaşadığını" gösteren ilk sinyaldir ve düzeltilmesi genellikle en düşük maliyetli performans işidir. Aklınızda kalması gereken dört alışkanlık şu: önce TTFB'yi ölçün çünkü tavanı o belirler, head içindeki senkron betiği sıfıra indirin, kritik CSS'i 14 KB civarında tutup gerisini asenkron yükleyin ve her yazı tipine font-display: swap ekleyin. Bu dördü yapıldığında çoğu sitede FCP bir saniyenin altına iner.

TTFB tarafında bir tavana çarptıysanız çözüm yapılandırmadan çok altyapıdadır. Ayrılmış kaynak ve NVMe disk için VDS veya sanal sunucu paketlerimize, hazır optimize edilmiş bir başlangıç için web hosting ve WordPress hosting planlarımıza bakabilirsiniz. Ölçüm ve iyileştirme döngüsünü sizin yerinize yürütmemizi isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.