Bir sayfa açıldığında kullanıcı ilk anda tam içeriği beklemez; önce “bir şey geliyor mu?” sorusuna cevap arar. FCP yani First Contentful Paint tam bu ilk algı anını ölçer. Tarayıcı ilk kez görünür bir metin, görsel, SVG ya da canvas parçası çizdiğinde FCP oluşur. Bu yüzden metrik yalnız teknik bir yükleme detayı değil, sayfanın boş ekrandan gerçek içeriğe geçtiği ilk hissi temsil eder. Kullanıcı gözüyle bakınca bu, sitenin canlı mı yoksa ağır mı hissettirdiğini belirleyen ilk eşiğe karşılık gelir.
Çoğu ekip performans tartışmasına doğrudan LCP veya toplam yükleme süresiyle başlar. Oysa FCP bozuksa kullanıcı sayfanın başladığını geç fark eder ve daha büyük metrikler daha sorunlu hissedilir. İlk içerik boyaması zayıf olan sayfada, üst bölümde boş alan, geç gelen web fontları, geç boyanan başlıklar veya CSS yüzünden görünmeyen iskelet yapılar sık görülür. Sayfanın bu ilk anını metrik bazında görmek isterseniz, ilk ekran davranışını ve render sırasını birlikte ölçmek en sağlıklı başlangıç noktalarından biridir.
FCP’yi iyileştirmek çoğu zaman devasa yeniden yazımlar gerektirmez. Ama sorunu doğru katmanda aramak gerekir. Bazen sunucu geç cevap verir, bazen kritik CSS geç çözülür, bazen gereksiz JavaScript ilk çizimi bloke eder. FCP’nin iyi tarafı şudur: sorun alanı doğru ayrıldığında hızlı kazanımlar üretme potansiyeli yüksektir. Kötü tarafı ise birçok küçük gecikmenin birleşerek metriği bozabilmesidir.
FCP tam olarak neyi ölçer?
First Contentful Paint, tarayıcının ilk kez boş olmayan bir piksel çizdiği anı ölçer. Bu piksel çoğu zaman gerçek bir metin bloğu, logo, ikon, arka plan dışındaki bir görsel ya da SVG tabanlı bir öğe olur. Yani FCP, “HTML geldi mi” sorusunu değil, “kullanıcı ekranda ilk anlamlı işareti ne zaman gördü” sorusunu cevaplar. Bu ayrım önemlidir; çünkü ağ tarafında bir hareket başlamış olabilir ama kullanıcı hâlâ boş ekran görüyor olabilir.
FCP ile “sayfa interaktif hale geldi” ya da “asıl içerik tamamen göründü” gibi daha ileri aşamalar karıştırılmamalıdır. FCP yalnızca ilk görünür içerik anıdır. Bu nedenle bazen iyi FCP, kötü genel deneyimle birlikte de görülebilir. Sayfa çok erken bir başlık boyar ama asıl içerik çok sonra gelir. Yine de kötü FCP çoğu durumda kötü ilk izlenim anlamına gelir. Çünkü kullanıcı bir şey görmeden bekliyorsa sitenin canlı olduğuna geç ikna olur.
İlk görünen şey neden bu kadar önemli?
Kullanıcı algısı teknik yükleme aşamalarını tek tek ayırmaz. O yalnızca sayfanın tepki verip vermediğine bakar. İlk içerik geç geliyorsa, “site açılmıyor” hissi oluşur. Bu his birkaç yüz milisaniye farkta bile büyüyebilir. Özellikle mobil cihazlarda ve daha yavaş bağlantılarda, boş ekran süresi orantısız biçimde daha ağır hissedilir. Bu yüzden FCP çoğu zaman sayfanın algılanan hızıyla güçlü korelasyon taşır.
FCP aynı zamanda başka darboğazların erken sinyalini verebilir. Sunucu gecikmesi, render-blocking CSS, geç yüklenen fontlar veya ağır ilk parti script’ler çoğunlukla önce bu metriği etkiler. Yani FCP bazen asıl sorunun kendisi değil, ilk habercisidir.
İyi FCP değeri kaçtır ve ne zaman sorun sayılır?
Pratikte iyi FCP çoğu projede 1.8 saniye ve altı olarak düşünülür. 1.8 ile 3 saniye arası iyileştirme alanı sayılabilir. Bunun üzeri ise ilk algı açısından ağır hissedilmeye başlar. Elbette bu aralıklar sayfa tipine, cihaz sınıfına ve bağlantı kalitesine göre değişir. Ancak metrik yorumlarken bir referans eşiğe sahip olmak, optimizasyon önceliği belirlemek için yararlıdır.
| FCP aralığı | Yorum | Pratik etkisi |
|---|---|---|
| 0 - 1.8 sn | İyi | Kullanıcı sayfanın başladığını hızlıca görür. |
| 1.8 - 3 sn | İyileştirilebilir | İlk ekran hafif ağır hissedilir. |
| 3 sn üzeri | Zayıf | Boş ekran süresi dikkat çekecek kadar uzar. |
Bu sınırları değerlendirirken laboratuvar testi ile gerçek kullanıcı koşulunu ayırmak gerekir. Masaüstünde hızlı bağlantıyla 1.5 saniye görünen bir sayfa, orta seviye mobil cihazlarda 2.5 saniyeyi aşabilir. O yüzden tek bir iyi skorla rahatlamak yerine, şablon bazında tutarlılığa bakmak daha anlamlıdır. Özellikle anasayfa, kategori sayfası ve blog şablonları farklı FCP profilleri üretebilir.
Burada önemli bir ayrım daha var: FCP iyi diye kullanıcı deneyimi otomatik iyi olmaz. Ancak kötü FCP çoğu zaman kötü başlangıç demektir. Bu nedenle metrik, tek başına yeterli olmasa da ilk optimize edilmesi gereken alanlardan biridir.
FCP’yi en çok hangi şeyler geciktirir?
İlk büyük gecikme çoğu zaman sunucu yanıtında başlar. HTML belge geç geliyorsa tarayıcı ilk görünen öğeyi oluşturmak için zaten geç çalışmaya başlar. Ancak FCP’yi sık bozan ana katman genellikle render-blocking kaynaklardır. Özellikle büyük CSS dosyaları, üst bölüm için gerekmeyen ama baştan indirilen stiller ve ilk çizimden önce çalışan JavaScript paketleri tarayıcının ilk boyamayı ertelemesine neden olur.
Web fontları da önemli bir etkendir. Başlık ya da navigasyon özel font bekliyorsa, tarayıcı bazen metni hiç göstermeden bekleyebilir ya da sonradan değiştirir. Bu durum FCP’yi ve algılanan kararlılığı birlikte bozar. Üstelik sorun yalnız dosya boyutu değildir; fontun ne zaman keşfedildiği, kaç varyant istendiği ve preload kullanılıp kullanılmadığı da sonuç üretir.
Bir diğer yaygın darboğaz, ilk ekran için gereksiz JavaScript yüküdür. Slider, animasyon, A/B test kodları, üçüncü parti izleme script’leri ve etkileşim gerektirmeyen bileşenler ana thread’i gereksiz biçimde meşgul eder. Sayfa bir başlık boyayacak kadar hafif görünse bile, bu işler ilk çizimi birkaç yüz milisaniye erteleyebilir. Bu durumda kodun tamamını küçültmekten çok, ilk ekran için gereksiz parçaları ayırmak daha etkili olur.
FCP problemlerinde görseller de rol oynayabilir, fakat LCP kadar belirleyici olmayabilir. Yine de üst bölümde büyük logo, SVG illüstrasyon veya arka plan dışı dikkat çekici medya varsa bunların erken keşfi önemlidir. Sorun çoğu zaman tek bir kaynakta değil; HTML, CSS, font ve script katmanlarının birleşik etkisindedir.
Render-blocking kaynaklar neden FCP için kritiktir?
Tarayıcı ilk görünür içeriği boyamak için önce HTML’yi çözer, gerekli stilleri toplar, düzeni hesaplar ve ardından boyamaya geçer. Eğer bu zincirin önüne büyük CSS dosyaları veya senkron çalışan script’ler girerse ilk içerik boyaması bekler. Bu yüzden FCP tarafında en sık duyulan terimlerden biri render-blocking’dir. Dosya küçük görünse bile ilk çizimden önce zorunlu hale gelmişse etkisi büyür.
Burada ilk yapılacak iş, ilk ekran için gerçekten gereken CSS ile geri kalan stilleri ayırmaktır. Her sayfada aynı devasa stil paketi baştan yükleniyorsa, kullanıcı yalnız üst bölüm başlık ve birkaç blok görecek olsa bile tüm site yükünü bekler. Bu noktada CSS ve JavaScript yükünü küçültmek ve gereksiz karakterleri temizlemek tek başına yeterli olmasa da ilk çizim yükünü hafifletir. Asıl kazanç ise kritik olmayan kaynakların ilk boyamadan sonra devreye alınmasından gelir.
JavaScript tarafında `defer`, `async`, kod bölme ve gereksiz ilk ekran bileşenlerini erteleme stratejileri devreye girer. Ancak bunları kör uygulamak risklidir. Örneğin üst bölümde gerçekten çalışan bir navigasyon ya da kritik tema script’i varsa bunu yanlış ertelemek görsel hatalar yaratabilir. Bu nedenle amaç her şeyi geciktirmek değil, ilk boyamaya engel olmayanları ayırmaktır.
Önbellekleme ve sıkıştırma da bu katmanı destekler. Doğru yapılandırılmış önbellek başlıkları ve aktarım optimizasyonları, özellikle tekrar ziyaretlerde ciddi fark yaratır. Sunucu düzeyindeki temel teslimat ayarlarını toparlamak için önbellek ve sıkıştırma davranışını .htaccess tarafında düzenlemek ilk ekran yükünü dolaylı ama önemli biçimde iyileştirebilir.
FCP ile LCP farkı neden karıştırılmamalı?
FCP sayfanın ilk kez canlı göründüğü andır. LCP ise kullanıcıya en büyük ve anlamlı içeriğin göründüğü anı temsil eder. Bu yüzden FCP daha erken, LCP daha geç gelir. Bir sayfada hızlıca küçük bir başlık boyanabilir; bu FCP’yi iyi gösterir. Ama büyük hero görsel veya ana içerik bloğu geç gelirse LCP kötü kalabilir. İki metriği aynı sanmak yanlış teşhis üretir.
Pratikte şöyle düşünmek faydalıdır: FCP “başladı”, LCP “esas içerik geldi” demeye daha yakındır. Bu yüzden FCP çalışırken küçük ama kritik görünürlük sorunlarına, LCP çalışırken büyük ana öğeye odaklanırsınız. Biri iyi, diğeri kötü olabilir. Mesela metin erken boyanır ama büyük görsel geç gelir. Böyle durumda FCP iyi, LCP zayıf kalır.
İki metriğin farkını anlamak önemlidir çünkü çözüm yolları tam örtüşmez. FCP tarafında kritik CSS, font teslimi ve render-blocking script’ler daha çok öne çıkar. LCP tarafında ise hero görsel boyutu, kaynak önceliği ve büyük öğe teslimi daha ağır basar. Büyük içerik öğesinin neden geç geldiğini ayrıca incelemek isterseniz, LCP üzerinde kurulan teşhis mantığı FCP ile ayrımı netleştirir.
FCP iyileştirmesi nasıl test edilmeli?
En sık yapılan hata, birkaç optimizasyon yapıp tek bir test sonucu üzerinden karar vermektir. Daha güvenli yöntem, önce şablon bazında sorunlu sayfaları ayırmak, sonra değişiklikleri tek tek uygulamaktır. Kritik CSS ayrımı, script erteleme, font optimizasyonu ve önbellek ayarlarını aynı anda değiştirmek, hangi dokunuşun gerçekten işe yaradığını görünmez hale getirir.
Ölçüm sırasında şu sırayı izlemek iyi sonuç verir: önce sunucu yanıtı ve HTML geliş süresi, sonra ilk çizimi bloke eden CSS/JS, ardından font davranışı, son olarak ilk ekran varlıkları. Bu katmanlar ayrı ayrı izlendiğinde FCP düşüşünün nerede oluştuğu daha net görünür. Bir şablonda sorun fonttan gelirken, başka bir şablonda ağır script ana sebep olabilir.
Burada amaç “1.8 saniyenin altına düştük, iş bitti” demek değildir. Kullanıcı ilk ekranda ne görüyor, bu görünüm kararlı mı, ilk boyamadan hemen sonra düzen sıçraması oluyor mu, asıl içerik kısa süre içinde geliyor mu? Bu sorular birlikte düşünülmelidir. FCP iyi ama kullanıcı gözünde başlangıç hâlâ rahatsızsa, muhtemelen metrik iyi görünürken deneyim tarafında başka problem vardır.
İyi FCP çalışması, boş ekran süresini azaltır ve kullanıcının sayfanın gerçekten açıldığını erken fark etmesini sağlar. Bu yüzden küçük iyileştirmeler bile güçlü hissedilebilir. Fakat çözümün kalıcı olması için teşhisin doğru yapılması gerekir. Render-blocking sorununu font sorunu sanmak ya da TTFB problemini CSS küçültmeyle çözmeye çalışmak çoğu zaman boş efor üretir.
FCP’yi iyileştirmenin en temiz yolu, ilk ekranda görünen gerçekten gerekli içeriği hızlıca boyatmaktır. Bunun için HTML’nin erken gelmesi, kritik stillerin ilk çizime engel olmaması, fontların ölçülü kullanılması ve gereksiz script yükünün ertelenmesi gerekir. Sayfa ilk anda canlı görünmeye başladığında, kullanıcı deneyiminin geri kalanı için çok daha güçlü bir temel oluşur.
Bu yüzden FCP çalışması küçük bir metrik düzeltmesi gibi görülmemeli. Aslında ilk izlenimi toparlama işidir. Sayfanın kullanıcıya “hazırım” demesi ne kadar gecikirse, devamındaki tüm performans iyileştirmeleri daha az görünür olur. İlk içerik boyaması erken ve kararlı geldiğinde, sayfa henüz tamamen yüklenmeden bile daha hızlı hissedilir.