FCP ve LCP Arasındaki Fark Nedir?

İlk içerik görünmesi ile ana içerik gelmesi aynı an değildir

FCP, tarayıcının ilk kez metin, görsel, SVG ya da canvas gibi gerçek bir içerik parçasını ekrana bastığı anı ölçer. Boş beyaz sayfanın ilk kez “bir şey göstermeye” başladığı nokta budur.

LCP ise görünür alandaki en büyük içerik parçasının ne zaman tamamlandığını izler. Çoğu zaman bu büyük kahraman görseli, ana başlık bloğu ya da geniş bir banner alanı olur. Kullanıcının “sayfa gerçekten geldi” duygusu daha çok bu metrikle ilişkilidir.

Bu yüzden FCP hızlı diye sayfanın iyi durumda olduğu varsayılmaz. İlk piksel erken gelebilir, ama esas yükü taşıyan büyük içerik geç kalıyorsa kullanıcı bekleme hissini sürdürür. Tam tersine LCP makulken FCP zayıfsa, sayfa uzun süre boş kalmış gibi algılanabilir.

FCP daha çok ilk algıyı anlatır

Kullanıcı sayfayı açtığında ilk birkaç yüz milisaniyede ekran hâlâ boşsa, hızlı bir sunucu yanıtı alınsa bile deneyim cansız görünür. FCP burada önemli bir işaret verir: tarayıcı gerçekten ilk içeriği ne kadar erken gösterebildi?

Bu aşamada kritik CSS yüklemesi, font davranışı ve bloklayan kaynakların miktarı ciddi rol oynar. Özellikle critical CSS düzeni zayıfsa veya render blocking kaynaklar fazla ise FCP gereksiz yere ötelenir.

FCP çoğu durumda “sayfa boş mu kaldı, yoksa hızlıca bir iskelet içerik mi gösterdi” sorusunu cevaplamak için yararlıdır. Bu yüzden navigasyon sonrası ilk algıyı iyileştiren değişikliklerde öne çıkar. İlk başlığın görünmesi, üst alanın boyanması ya da temel gövde metninin ekrana düşmesi bu metriği toparlayabilir.

Yine de FCP'nin güçlü olması tek başına yeterli değildir. Erken görünen içerik bazen çok küçük bir metin satırıdır; kullanıcı için asıl değerli bölüm daha sonra geliyorsa metrik iyi görünse bile deneyim tam olarak tatmin edici kalmayabilir.

LCP kullanıcının beklediği ana yükü yakalar

LCP genelde görünür alandaki en büyük öğeyi izlediği için, kullanıcıya gerçekten “sayfa geldi” hissini veren anı daha güçlü biçimde temsil eder. Bu öğe büyük bir görsel olabilir, ama her zaman resim olmak zorunda değildir; geniş bir başlık bloğu da LCP adayı haline gelebilir.

Bu metrikte en sık karşılaşılan sorunlar ağır kahraman görselleri, geç çözülen fontlar, geç başlayan istek zincirleri ve istemci tarafında oluşturulan büyük bileşenlerdir. Mesela ilk boyama erken olsa bile ana hero görseli geç yükleniyorsa LCP yüksek çıkar.

Lazy loading stratejileri burada da yanlış uygulanırsa ters etki yaratabilir. Ekranın üstündeki büyük görseli tembel yüklemeye almak, FCP'yi değil ama LCP'yi doğrudan geciktirebilir. Aynı şekilde hero alanında gereğinden büyük medya kullanmak da ana içeriğin geç tamamlanmasına neden olur.

LCP'nin neden bu kadar kritik görüldüğü basit: kullanıcı genelde ilk küçük sinyale değil, görmek için geldiği büyük ana alana göre karar verir. Haber başlığı, kategori hero bölümü ya da ürün görseli geç geliyorsa sayfa teknik olarak açılmış olsa bile yavaş hissedilir.

Aynı raporda biri iyi, diğeri kötü çıkabilir

Sık görülen senaryolardan biri şudur: küçük başlık metni hızlıca görünür, dolayısıyla FCP makul çıkar; fakat büyük görsel ya da ana içerik bloğu geç yüklendiği için LCP zayıf kalır. Bu durumda ekip boş ekran sorununu çözmüştür ama ana içeriğe erişim hissi hâlâ gecikmektedir.

Tersi de mümkündür. Örneğin sunucu ve kritik kaynaklar iyi yönetildiği için ana içerik bloğu hızlı tamamlanır, ama ilk birkaç yüz milisaniyede kullanıcı boş ya da neredeyse boş ekran görür. Bu kez LCP görece iyi dururken FCP zayıf kalabilir.

Bu ayrım özellikle Lighthouse raporunu yorumlarken önemlidir. Tek metrik üzerinden genelleme yapmak, sorunun hangi katmanda olduğunu gizler. İlk içerik mi geç başlıyor, yoksa ana içerik mi geç tamamlanıyor? Bu iki sorunun cevabı farklı optimizasyon kararlarına çıkar.

Pratikte kullanıcı tarafındaki şikâyet dili de bunu doğrular. “Sayfa uzun süre boş kaldı” ile “sayfa açıldı ama ana bölüm geç geldi” aynı problem değildir. İlk cümle FCP tarafına, ikincisi çoğu zaman LCP tarafına daha yakındır.

Her metrik farklı optimizasyon kararlarına işaret eder

Her iyileştirme iki metriğe aynı ağırlıkta dokunmaz. Bazı hamleler ilk boyamayı öne çekerken, bazıları ana içeriğin tamamlanma süresini kısaltır.

• FCP tarafında daha etkili olanlar: kritik CSS çıkarımı, üst alandaki bloklayan kaynakları azaltma, gereksiz font yüklerini düşürme, temel üst alanı hızlı boyatacak HTML düzeni.
• LCP tarafında daha etkili olanlar: hero görselini küçültme, doğru format kullanma, öncelikli isteği erkene çekme, ağır ana bileşenleri istemci tarafında geç üretmekten kaçınma.
• İkisini birlikte etkileyebilenler: sunucu yanıtını iyileştirme, CDN kullanımı, gereksiz JavaScript yükünü azaltma, istek zincirlerini kısaltma.

Bu yüzden metrikle çözüm arasında birebir harita kurmak faydalıdır. Erken boyama gerekiyorsa ilk katmanlara, ana içerik geç kalıyorsa büyük görünür öğeye bakmak daha verimli sonuç verir. Aksi halde ekip doğru işi yanlış sebep için önceliklendirmiş olur.

Genel hız hissi aslında bu iki katmanın toplamından doğar. Biri toparlanıp diğeri dağınık kaldığında kullanıcı tarafı hâlâ yarım iyileşme hisseder.

İki metriği birlikte okumak daha sağlıklıdır

FCP ve LCP'yi beraber okumak, “ne zaman bir şey görünmeye başladı” ile “ne zaman asıl görünmesi gereken şey geldi” ayrımını netleştirir. Özellikle sayfanın üst alanı yoğun tasarlandıysa bu iki çizgi birbirinden kolayca açılabilir.

Sağlam bir okuma için önce görünür alandaki LCP adayını bulun, sonra FCP'nin o noktaya göre ne kadar erken geldiğine bakın. Aradaki fark çok büyüyorsa, sayfa ilk sinyali veriyor ama ana yükü geç tamamlıyor demektir. Fark küçük ama ikisi de yüksekse, sorun daha temel kaynak teslimatında olabilir.

Bu noktada FCP ile LCP'yi tek başına değil, sayfanın şablonuna göre yorumlamak gerekir. Metin ağırlıklı bir blog yazısında fark daha dar olabilir. Büyük hero kullanan bir landing kurgusunda ise farkın açılması daha olasıdır. Sayfa tipini hesaba katmadan kıyaslama yapmak yanıltıcıdır.

Ayrıca etkileşim sonrası deneyim de önemini korur. Sayfa yüklenme metrikleri makul olsa bile kullanıcı komutlarına geç cevap veriliyorsa, o noktada INP metriği devreye girer. Böylece yüklenme ve kullanım tarafını birbirine karıştırmadan okuyabilirsiniz.

Mobilde fark daha belirgin hissedilir

FCP ile LCP arasındaki mesafe özellikle mobil cihazlarda daha görünür hale gelir. Bunun temel nedeni yalnızca ağ hızının düşük olması değildir; işlem gücünün sınırlı olması, görsel çözümleme maliyeti ve ana iş parçacığındaki küçük gecikmelerin daha çabuk büyümesidir.

Masaüstünde hızlı çözülen bir büyük görsel, orta seviye telefonda daha geç boyanabilir. Aynı şekilde font yükü, üst alan düzeni ve istemci tarafında çalışan bileşenler mobilde birbirini daha sert etkiler. Sonuçta FCP ile ekranda ilk hareket görülür, fakat LCP'ye giden asıl yol beklenenden daha uzun sürer.

Bu yüzden mobil performans raporlarında şu soruya özellikle bakmak gerekir: üst alanda görünen en büyük öğe gerçekten erken mi başlıyor, yoksa yalnızca küçük bir metin parçası kullanıcıyı oyalıyor mu? Eğer ikinci durum varsa FCP makul görünse bile deneyim zayıf kalır.

Pratikte mobilde farkı azaltan işler genelde daha disiplinli üst alan tasarımıyla gelir. Daha hafif hero görselleri, daha az katmanlı giriş alanı, gereksiz dekoratif medya yerine daha sade görünür içerik ve ilk ekran için daha net kaynak önceliği bu ayrımı daraltabilir.

En yaygın yanlış yorumlar

İlk hata, FCP'nin iyi olmasını “sayfa hızlı” diye etiketlemektir. Oysa kullanıcı çoğu zaman ilk küçük işareti değil, ana içeriğin görünür hale geldiği anı önemser. Bu yüzden yalnızca erken boyama görmek, işin bittiği anlamına gelmez.

İkinci hata, LCP'yi sadece görsel metriği sanmaktır. Görünür alandaki en büyük öğe bazen başlık ya da büyük metin bloğu olabilir. Sorunu çözmek için önce gerçek LCP adayını bulmak gerekir; aksi halde ekip yanlış görseli optimize edip yerinde sayabilir.

Üçüncü hata da metrikleri sayfa türünden bağımsız yorumlamaktır. Haber yazısı, ürün detay sayfası ve kampanya hero'su aynı üst alan ağırlığına sahip değildir. Bu yüzden FCP ile LCP farkının “her sayfada aynı seviyede olmasını” beklemek çoğu zaman yapay bir hedef üretir.

Dördüncü yaygın yanlış, tek ölçüm sonucuna fazla güvenmektir. Ağ dalgalanması, font cache durumu, cihaz sınıfı ve görsel çözümleme süresi farklı koşullarda değişebilir. Bir raporda görülen farkı doğrulamak için aynı sayfayı benzer koşullarda birkaç kez ölçmek daha sağlıklı olur.

Öncelik verirken tek doğru cevap yoktur

Hangi metriğin önce ele alınacağı sayfanın sorun biçimine bağlıdır. Ekran uzun süre boş kalıyorsa FCP tarafına, ana içerik geç geliyorsa LCP tarafına öncelik vermek daha doğru olur. Bazen bu iki alan birbirine yakın işlerle de toparlanabilir, ama çoğu projede biri diğerine göre daha belirgin darboğaz taşır.

Ekiplerin sık yaptığı hata, yalnızca daha popüler olduğu için LCP'ye yüklenmek ya da ilk iyileşmeyi hızlı gösterdiği için FCP ile yetinmektir. Oysa kullanıcı hissi, boş ekran süresi ile ana içerik gecikmesinin birlikte kurduğu toplam deneyimden oluşur.

Daha iyi yaklaşım şudur: önce görünür sorunu tanımlayın, sonra o soruna daha yakın olan metriği lider gösterge olarak izleyin. İkinci metriği ise denge ölçüsü olarak kenarda tutun. Böylece bir alanı toparlarken diğerini istemeden bozup bozmadığınızı daha erken fark edebilirsiniz.