LCP'yi merak eden arkadaşlarımız okuyabilir.
Largest Contentful Paint (LCP), bir web sayfasının yükleme süreci içerisinde sayfanın en büyük içeriğinin oluşturulma (render) süresinin ölçümlendiği metriğe verilen isimdir. Google’ın Core web vitals metrikleri adı altında aktif olarak kullanmakta olduğu LCP metriği ile web sayfasında yer alan ve kullanıcının viewport’u içerisinde görüntülenebilir durumda olan en büyük elementin sayfada oluşturulduğu süre ölçümlenir. Sayfa açılış hızları kapsamında ölçümlenen bu metrik ile sayfayı ziyaret eden kullanıcıların açılış hızları kaynaklı algısal deneyimleri ölçümlenmektedir.
Google’ın 2021 yılı yaz döneminde mobil arama sonuçları için algoritma içerisinde aktif ettiği Core web vitals metrikleri ile birlikte Largest contentful paint metriği aktif olarak açılış hızları kaynaklı kullanıcı deneyimi ve özellikle algısal açılış hızlarının ölçümlenmesinde kullanılan metriklerden bir tanesi olmuştur.
Largest contentful paint metriği kendisi gibi sayfa açılış hızı metrikleri olan Time To First Byte (TTFB), First Contentful Paint (FCP), Speed Index gibi metrikler ile yakından ilişkilidir. TTFB metriğinde yani sunucu tarafında istemciden gönderilen isteklere verilen cevaplarda yaşanacak yavaşlık doğrudan LCP metriğinin sonuçlarını da etkileyeceğinden bu ve benzeri pek çok sayfa açılış hızı metriği LCP ile yakından ilişkilidir.
İdeal (Başarılı) LCP Skoru Nedir?
LCP Zamanı (Milisaniye)Değerlendirme (Renk Kodu)0-2500Hızlı (Yeşil)2500-4000Orta – Geliştirilmesi Gerekiyor (Turuncu)4000 ve üstüYavaş (Kırmızı)
Üstteki tabloda görüntüleyebileceğiniz gibi 0 ila 2.5 saniye (2500 ms) arasında gerçekleşen LCP skoru ölçümlemeleri Google tarafından başarılı olarak kabul edilmektedir. 2500 ms ile 4000 ms arasında gerçekleşen LCP skorları orta ancak geliştirilmeye ihtiyacı olan skorlar olarak kabul edilirken 4000 ms ve üzeri skorlar Google tarafından başarısız ve yavaş olarak kabul edilmektedir.
Bu noktada 2500 ms ve üstü skorlara sahip tüm web siteleri için LCP skorlarını iyileştirmeye yönelik optimizasyonların hayata geçirilmesi gereklidir.
Search console üzerinde bir web sitesinin mobil veya masaüstü core web vitals skorlarının başarılı kabul edilebilmesi için kullanıcı verilerinin %75 ve üstünün ideal skorlara sahip olması gereklidir. Örneğin LCP değeri için ölçümleme yapılırken kullanıcı verilerinin (CrUX) %75’inde LCP skoru 2.5 saniye ve altında ise ilgili web sayfasının ilgili mobil veya masaüstü skoru başarılı kabul edilir ve search console da good (iyi) olarak işaretlenir.
LCP Metriği Ölçümlenirken Dikkate Alınan Elementler Hangileridir?
Bir web sayfasında Largest Contentful Paint ölçümlemesi gerçekleştirilirken değerlendirmeye alınan elementler aşağıdakilerdir ;
- <img> resim elementleri
- svg etiketi içerisindeki <image> elementleri
- Inline (satır içi) ve blok metin elementleri (<p>, <h> vb.)
- CSS url property kullanılanılarak sayfada yüklenen görseller
- <Video> elementleri
Bir web sayfasında ölçümlenen LCP elementi genellikle büyük bir text node’si (uzun bir paragraf) yada büyük boyutlu bir öne çıkan (hero) görseldir.
Bir LCP Elementinin Boyutu Nasıl Değerlendirilir?
En Büyük İçerikli Boyama (LCP) için belirtilen sayfa elementinin boyutu, ilgili elementin kullanıcı tarafından görünüm alanında (viewport’da) görünen kısmına göre hesaplanır. Herhangi bir elementin kullanıcı görünüm alanı olan viewport dışarısında kalan, taşan yada kırpılmış bölümü LCP elementinin boyutunu etkilemez.
Resim Elementleri için LCP Boyutu Nasıl Ölçülmektedir?
LCP olarak belirtilen bir görselin boyutu ilgili görselin en küçük versiyonunun boyutuna göre hesaplanır. Örneğin; Orijinal versiyonundan farklı olarak sayfada en-boy genişliği arttırılan bir resmin genişletilmiş versiyonunun boyutu yerine ilgili görselin küçük ve gerçek versiyonunun (intrinsic) boyutu elementin LCP boyutu olarak değerlendirilir. Aynı şekilde bir görsel, gerçek boyutunun tersine küçültülmüş şekilde render edilmiş ise bu durumda da görselin gerçek boyutu yerine viewport içerisinde küçültülmüş halinin boyutu, LCP boyutu olarak değerlendirilir.
Metin (Text) Elementleri için LCP Boyutu Nasıl Ölçülmektedir?
LCP metriği ile alakalı metin elementlerinin boyut hesaplaması gerçekleştirilirken metin öğeleri için yalnızca metin düğümlerinin (node) boyutu dikkate alınır. Büyük boyutlu bir metin elementini içinde barındıran en küçük dikdörtgen olan node (düğüm) <p> , <h1> vb üzerinden metin elementinin boyutu hesaplanır
Örneğin:
<div class=”content”>
<p>
İlk paragraf
<p> —- LCP
İlk paragraftan daha büyük boyutlu, daha çok yazı içeren ilk paragrafın içerisindeki ikinci paragraf.
</p>
</p>
</div>
Üstteki kod akışı örneğinde bir p düğümünün (nodesinin) içerisinde bulunan ikinci p düğümünün boyutu parent nodesi olan <p> etiketinden büyük olduğu için bu hesaplamada en küçük dikdörtgen olan ikinci P etiketinin boyutu LCP boyutu olarak değerlendirmeye alınır.
Bu örneğin tersi durumda p elementlerini içerisinde barındıran <div class=”content”> </div> nodesi başka bir p node içermeden boyutu büyük bir metni düz bir şekilde içerir ise ilgili elementin alt nodesi (elementi) olan tüm <p> nodeler div elementinin boyutuna dahil edilir ve div elementinin boyutu LCP boyutu olarak hesaplanır.
Özetle: Metin öğeleri için LCP boyut hesaplaması büyük boyutlu metni içeren en küçük dikdörtgen, node (etiket, element) üzerinden hesaplanır.
Önemli: Tüm öğeler için (Resim, text vb) LCP değerlendirmesi yapılırken CSS aracılığıyla uygulanan herhangi bir kenar boşluğu, dolgu veya kenarlık dikkate alınmaz.
LCP Elementleri Tarayıcılarda Ne Zaman ve Nasıl Rapor Edilir ?
Tarayıcıların çalışma prensibi gereği web sayfalarının parse ve render edilmesi süreci aşama aşama tamamlanır. Bu noktada LCP değeri (süreleri) tarayıcılarda raporlanırken aşama aşama sayfa yüklendikçe sayfanın en büyük boyutlu elementi ve bu elementinin yüklenme süresi değişiklik gösterebilir.
Tarayıcıda gerçekleşen sayfa yükleme döngüsü içerisinde sayfada yer alan elementler render edildikçe sayfanın LCP elementi sayfada yüklenen yeni elementlere göre değişiklik gösterebilir. Sayfanın above the fold bölümünde kullanıcının viewport’unda yer alan herhangi bir element ilk yüklendiğinde LCP elementi olabilir. Devamında ilgili elementden daha büyük boyutlu başka bir element sayfada yüklendiğinde sayfanın LCP elementi ve LCP elementinin yüklenme süresi değişiklik gösterir.
Örneğin: Sayfanın yükleme döngüsü içerisinde ilk olarak render edilen (oluşturulan) bir <h1> başlığı, en büyük içerikli öğe olarak belirlenerek bu elementin yüklendiği süre LCP skoru olarak belirlenebilir. Devamında sayfa yüklendikçe oluşturulan farklı bir metin yada görsel öğe (resim vb), sayfanın en büyük içerikli öğesini değiştirerek LCP skorunu değiştirebilir.
Yaşanan LCP değişikliklerini ölçümlemek adına tarayıcı, ilk kareyi boyadığı anda en büyük içerikli öğeyi tanımlayan largest-contentful-paint türünde bir PerformanceEntry gönderir. Sayfa yükleme döngüsü içerisinde tarayıcı, sonraki kareleri oluşturdukça en büyük içerikli öğe (element) her değiştiğinde başka bir PerformanceEntry gönderir.
Örneğin: Yalnızca bir h1 başlığı ve yüksek boyutlu resimden oluşan bir sayfada tarayıcı, ilk olarak sayfanın h1 başlığını oluşturduktan sonra LCP elementini ölçümlemek adına largest-contentful-paint PerformanceEntry’i gönderir. Devamında sayfanın en büyük boyutlu elementi olan görsel dosyası yüklendiğinde tarayıcı ikinci PerformanceEntry’i gönderir. Tarayıcı tarafından sayfanın h1 başlığı oluşturulduktan sonra gönderilen PerformanceEntry’nin element özelliğinde <h1> başlığı yer alırken daha büyük boyutlu görselin yüklenmesi sonrası gönderilen PerformanceEntry’nin element bölümünde yeni yüklenen görsel <img> yer alır.
Bir elementin LCP elementi olarak değerlendirmeye alınabilmesi için ilgili elementin kullanıcı tarafından viewportda görüntülenebilir durumda olması gereklidir. Web font kullanılarak oluşturulan ve font yükleme süreci blok durumunda olan metinler ve henüz sayfada yüklenmemiş resimler sayfanın en büyük boyutlu elementleri olsalar da render edilene kadar en büyük boyutlu element olarak işlem görmezler.
Sayfada render edilen herhangi bir LCP elementi viewport’dan yada DOM içerisinden silinse dahi yerine daha büyük boyutlu bir element render edilene kadar LCP elementi olarak kalır. Örneğin sayfada yüklenen büyük boyutlu bir görsel LCP elementi olarak belirlendikten sonra sayfadan silinse dahi herhangi bir kullanıcı aksiyonu gerçekleşmeden önce başka bir boyutlu element render edilene kadar LCP elementi olarak kalır.
En büyük boyutlu elementler ile alakalı gerçekleştirilen entry raporlaması (PerfromanceEntry) sayfada gerçekleşen bir kullanıcı aksiyonu ile sonlandırılır. Kullanıcı tarafından gerçekleştirilen herhangi bir click, scroll veya tuşa basma yeni PerformanceEntry gönderimlerini durdurur. Bu sebeple herhangi bir kullanıcı aksiyonu sonrası sayfada yüklenen elementler LCP elementi olarak değerlendirilmezler.
LCP Ölçümlemesinde Elementlerin Pozisyon ve Görsel Düzeni Nasıl Değerlendirilir?
PerformanceEntry sayısını düşük tutmak ve veri hesaplama maliyetini arttırmamak adına bir öğenin boyutunda veya konumunda yapılan değişiklikler yeni LCP girişi (Entry) oluşturmaz. Örneğin: İlk yüklendiğinde ekranın alt bölümünde render edilen bir öğe pozisyon değişimi sonrası viewport içerisine eklense dahi yeni performanceEntry, LCP oluşturulmaz (Aynı durum tersi içinde geçerlidir). Sayfadaki elementlerin render süreci içerisindeki ilk pozisyonları ve ilk boyutları dikkate alınır.
Bu bağlamda render edildikten sonra boyutu artan, azalan yada pozisyonu değişen öğeler için yeni PerformanceEntry oluşturulmaz.
LCP Metriğine Ait Veriler Nasıl Ölçümlenir ?
LCP metriği simüle edilmiş lab verisi ve gerçek kullanıcı verisi olmak üzere iki farklı şekilde ölçümlenebilir. LCP verilerinizi ölçümleyebileceğiniz araçlara aşağıdaki listeden ulaşabilirsiniz.
Kullanıcı Verilerini Ölçümleyebileceğiniz Araçlar
Aşağıda yer alan listedeki araçlar ile sitenizi ziyaret eden kullanıcılara ait verilerinizi görüntüleyebilirsiniz. Trafiği düşük, az sayıda kullanıcı popülasyonuna sahip siteler için kullanıcı verilerinde eksiklik olabilmektedir.
- Chrome User Experience Report
- PageSpeed Insights
- Search Console (Core Web Vitals report)
- web-vitals JavaScript library
Lab (Simüle) Edilmiş Verilerinizi Ölçümleyebileceğiniz Araçlar
WebPageTest.org ile LCP Ölçümleme
Webpagetest.org’u kullanarak sayfalarınızın tüm açılış hızları ile alakalı metriklerini, cihaz ve bağlantı hızı senaryolarını simüle ederek ölçümleyebilirsiniz.
Örneğin webpagetest.org üzerinde https://www.dijitalzade.com/seo-nedir/ sayfasını Almanyadan Chrome, Iphone 6-7-8 cihazlar ve 4g (ortalama) bağlantı hızını simüle ederek test ettiğimizde ortaya çıkan 0.9 saniyelik LCP değerini film şeridi (filmstrip) olarak görüntüleyebiliyoruz.
Üstte yer alan görselde görebileceğiniz gibi webpagetest.org’un film şeridi (filmstrip) özelliğini ve 0.1 saniye sürelere bölünmüş ekran görüntüsü özelliğini aktif ettiğinizde sayfanızın (özellikle mobil cihazlar için) ilgili viewportda simüle edilmiş yüklenme döngüsünü görüntüleyebilirsiniz. Buradaki örnekte sayfada sistem font kullanılarak oluşturulan h1 başlığı 0.9 – 1 sn aralığında sayfada render edilmektedir.
Başarısız LCP Skorlarının Temel Nedenleri Nelerdir?
Başarısız LCP skorlarının temel nedenleri aşağıda listelenmiştir ;
- Yavaş sunucu yanıt süreleri (TTFB)
- Client side rendering
- Render blocking CSS kaynakları
- Render blocking JavaScript kaynakları
- Optimize edilmemiş CSS ve JavaScript kaynakları
- Optimize edilmemiş font Yüklemeleri
- Optimize edilmemiş görseller
- Optimize edilmemiş yükleme hiyerarşisi (akışı)
- Hatalı lazy load uygulamaları
LCP Skorları Nasıl Optimize Edilir ?
Başarısız, ortalama LCP skorlarını Google’ın önerilen seviye olarak belirttiği 2.5 saniye ve altı sürelere optimize etmek için aşağıda önerdiğimiz iyileştirme çalışmalarını hayata geçirebilirsiniz.
1. Sunucu Optimizasyonu
İstemciden gönderilen isteklere geç yanıt veren sunucular web sayfalarının açılış sürelerini TTFB metriğine yani sunucunun istek gönderilen sayfa ile alakalı ilk yanıt (byte) döndürme süresine bağlı olarak geciktirirler. Herhangi bir web sayfası ile alakalı istek gönderen tarayıcı ilgili web sayfası ile alakalı kaynaklara ne kadar geç ulaşır ise ilgili web sayfasının açılış süresi aynı oranda gecikecektir. Bu bağlamda gelen isteklere yanıt verme süresi optimize edilmemiş, istemciden gelen isteklere yanıt vermede başarısız, yetersiz web sunucuları tüm web sitesinin sayfa açılış hızı performanslarını doğrudan etkileyecektir.
LCP skorları ile doğrudan bağlantılı TTFB metriğini ölçümleyerek sunucunuzun kullanıcı isteklerine ne kadar hızlı yanıt verdiğini gözlemleyebilir ve LCP skorlarınızı optimize edebilmek adına sunucunuzu yeniden yapılandırabilirsiniz.
TTFB metriğini optimize edebilmek adına sunucu tarafında hayata geçirebileceğiniz belirli optimizasyon fırsatları mevcuttur. Aşağıda yer alan listede ilgili optimizasyon fırsatlarını görüntüleyebilirsiniz ;
- Sunucu altyapı optimizasyonu
- Server side rendering
- CDN kullanarak kullanıcıları yakın serverlara yönlendirmek
- Kaynakların cachelenmesi (server cache)
- Brotli / Gzip sıkıştırmanın aktive edilmesi
- HTTP/2 ve HTTP/3 aktivasyonu.
- İstek sayısını azaltmak için HTTP/2 Server push
- Redis veya Memcache teknolojilerini sunucuda aktif edin
1.1 Sunucu Altyapı Optimizasyonu
Hızlı yanıt sürelerine sahip server inşa etmenin ilk ve en temel adımlarından bir tanesi başarılı veri işleme, yanıt sürelerine sahip web server yapılarını tercih etmektir. Bu noktada sitenizde kullandığınız alt yapı tercihinize göre veri işlemede başarılı Cherokee, Nginx, Litespeed, Microsoft IIS gibi web serverlarını tercih ederek TTFB metriğinizi optimize etmenin ilk ve en temel adımını atabilirsiniz.
12 Bytedan oluşan bir test sayfası üzerinden gerçekleştirilen web serverlar arası performans testi (yüksek değerler daha iyi sonuçları temsil eder)
12 Byte’lık bir hello world yazılı HTML dosyası üzerinden gerçekleştirilen testlerde web serverların performanslarını üstteki görselden görüntüleyebilirsiniz. Web server performanslarına yönelik gerçekleştirilen testlerde server optimizasyonu, sunucu donanım şartları gibi etkenler skorları etkileyebilmektedir.
Bu bağlamda donanım şartlarınıza ve site alt yapınıza uygun, hızlı web serverlarını tercih etmek TTFB skorlarını optimize etme noktasında size önemli avantajlar sağlayacaktır.
1 Core CPU’ya sahip sunucu üzerinde web server performans testleri
1 Core CPU’ya sahip sunucu üzerinde popüler web serverların yük altında ve saniyede işleyebildiği istek sayısı testleri
8 core CPU’ya sahip sunucu üzerinde gerçekleştirilen testlerde yük altında web serverların istek işleme kapasitelerindeki performans değişikliğini gözlemleyebilirsiniz. Testlerin gerçekleştirildiği sunucuların donanımsal özellikleri ve web serverların optimizasyon farklılıkları sonuçları etkileyebilmektedir. Buradaki verileri sunucu donanımları ve web serverlar arasındaki performans farklarını değerlendirmek adına örnek metrikler olarak kabul edebilirsiniz.
Web serverlar arası performans testleri (credit) : https://www.rootusers.com/linux-web-...-2016-results/
Tüm web serverların kendi yapısı dahilinde optimizasyon seçenekleri ve ek özellikleri mevcuttur. Web server tercihi yaparken sağladığı optimizasyon fırsatları ve temel yapısı içerisine dahil olan hız özelleştirmelerine dikkat edilmesi önemlidir. Örneğin gzip, brotli sıkıştırmaya müsade etmeyen, HTTP header da cache direktifleri giremediğiniz web serverlarda veri akış hızı, sayfa oluşturma süreleri artış göstereceğinden TTFB metriği ilgili durumdan negatif etkilenecektir.
Özellikle veri işleme noktasında yetersiz, yük altında zayıf bir backend performansına sahip web serverlarda çok daha kompleks işlem sorguları çalıştırmak ve özellikle statik cache olmaksızın, web sayfalarını dinamik olarak oluşturmak TTFB metriklerini negatif olarak etkileyecektir. Çünkü istemciden gelen istekleri cache olmadan sürekli olarak dinamik oluşturmak zorunda olan web serverlarda istemciden alınan istek sunucunun arka ucun da veritabanı ile gerçekleştirilen sorgu ve veri alışverişleri sonrasında oluşturulur. Web server yapılandırmasına ek olarak veritabanı noktasında da optimizasyon problemleri yaşayan sunucularda dinamik oluşturma süreci önemli ölçüde gecikecektir.
Statik web sayfalarına sahip web siteleri için sunucu tarafında server cache uygulaması ile statik kaynakların cachelenmesi sonrası sunucu yükünde azalma ve TTFB metriğinde iyileşme sağlamak mümkündür.
Dinamik web sayfası oluşturma süreçlerinde web server optimizasyonuna ek olarak sunucu donanım limitleri de (CPU, RAM) performansı doğrudan etkileyen bir diğer etmendir.
Web serverları (sunucuyu) optimize etme noktasında server tarafında işleyen kompleks operasyonları ve yoğun kod işlemlerini azaltmak ve özellikle dinamik sayfalar için veritabanı sorgularını basitleştirmek, veritabanı indeksini düzenlemek, Redis & memcache benzeri veritabanı cache teknolojileri kullanmak yanıt sürelerini optimize etmek noktasında katkı sağlayacaktır. Optimizasyon süreçlerinde özellikle kullandığınız web serverın teknik ekipleri tarafından paylaşılan optimizasyon yönergelerini (dokümanları) uygulamak yanıt sürelerini optimize etmede etkilidir.
Javascript tabanlı dinamik web sitelerinde server tarafında önbellekleme ile birlikte server side rendering teknolojisi kullanmak sunucu yanıt süresini azaltabilir. Klasik php (wordpress) web sayfalarında olduğu gibi sunucu tarafında oluşturulan ve cachelenen HTML doküman, javascript tabanlı web sitelerinde de server tarafında render edilerek cachelenebilir . Server side rendering yerine Kullanıcı tarafında render uyguladığında sunucunun yanıt süresi ve iş yükü azalırken tarayıcı tarafında sayfanın oluşturma süreci server tarafında oluşturulmuş bir sayfaya göre önemli ölçüde artış gösterebilir.
JavaScript tabanlı tek sayfa uygulamalarında (SPA) ilgili JS kütüphanelerinin yönlendirmeleri ile server rendering uygulanarak dinamik sayfalar statik olarak serverda oluşturularak cachelenebilir. Bu durumda server tarafında oluşturulan statik sayfalar belirli bir süre serverda saklanarak kullanıcıya tekrarlı ziyaretlerde çok daha hızlı TTFB skorları ile sunulabilir.
Javascript tabanlı web sitelerinin sunucu optimizasyonu ve Server side rendering ile alakalı kullandığınız framework’ün doküman yönergelerini uygulayabilirsiniz. ÖRN: React
1.2 CDN Kullanın
İçerik Dağıtım Ağı (CDN – Content Delivery Network), dünyanın birçok farklı konumunda barındırılan sunuculardan oluşan ve bu sunucular üzerinden kullanıcıların lokasyonuna göre içerik dağıtımı sağlayan sunucu ağlarına verilen isimdir. CDN kullanmak yerine sitenizin tüm kaynaklarını tek bir lokasyonda bulunan web sunucusunda barındırdığınızda siteniz özellikle dünyanın farklı lokasyonlarından bağlanan kullanıcılar için normalden daha geç yanıt döndürecektir. Sunucuların ve istemcilerin network uzaklığından kaynaklanan bu durumun önüne geçmek adına özellikle çok uluslu kullanıcıları bulunan web siteleri için CDN servisi kullanarak lokasyonlara özel sunuculardan içerik dağıtımı yapılması TTFB metriğinin ve LCP skorlarının optimize edilmesine katkı sağlayacaktır.
CDN servisi kullandığınız durumda dünyanın pek farklı lokasyonundan kullanıcıya en yakın olan serverdan sağlanan kaynaklar network gecikmesini minimuma indirerek kaynakların çok daha hızlı yüklenmesini sağlayacaktır. Buna ek olarak CDN servisleri üzerinde barındırılan statik kaynakların hızlı TTFB skoruna sahip, optimize edilmiş farklı sunucular üzerinden daha hızlı servis edilmesi ile hem ana sunucunun iş yükü azalacak hem de site kaynaklarının hızlı yüklenmesi ile sayfalar ve LCP elementleri çok daha hızlı yüklenecektir.
CDN servisinin kullanılmadığı ve sunucu donanımlarının yeterli olmadığı durumda tek kaynaktan beslenen web sitelerinde sunucunun yetersiz kaldığı senaryoda çok sayıda HTTP 5xx temelli sunucu çökme hataları ile karşılaşabilir. Özellikle hem kullanıcılar hem de Google bot için negatif sinyal olan bu durum doğrudan ve dolaylı olarak sitenizin rakiplerinizin gerisinde kalmasına sebebiyet verebilir.
1.3 Statik HTML Sayfalarını Server Tarafında Önbellekleyin
Üst bölümde yer alan 1.1 Sunucu altyapı optimizasyonu bölümünün alt kısmında değindiğimiz gibi web sayfalarınızı statik olarak server tarafında önbellekleyerek tekrarlı ziyaretler gerçekleştiren kullanıcıların site sayfalarınıza daha hızlı ulaşmasını sağlayabilirsiniz.
Server cache, PHP ve WordPress siteler için çeşitli cache eklentilerini, Cloudflare server worker CDN’i ve javascript tabanlı web sitelerinde de UI kütüphanelerinin yönlendirmelerini uygulayarak server side rendering ve server tarafında önbellekleme uygulayabilir, sayfa açılış hızlarını ve LCP değerlerinizi optimize edebilirsiniz.
Dinamik olarak oluşturulmuş web sayfalarınızı (HTML Dokümanı) statik olarak ister kendi serverınızın önbelleğinde isterseniz de çeşitli CDN, Proxy (cloudflare vb) servislerin sunucularında barındırabilirsiniz.
Örneğin Cloudflare Proxy ve CDN’i kullanan web siteleri page cache’i aktif ederek proxy serverlarda dinamik olarak oluşturulmuş sayfalarının final halini statik olarak önbellekleyebilirler. Cloudflare’in üst paketlerinde eklenen CDN servisi ile birlikte dünyanın pek çok farklı lokasyonunda önbelleklenmiş HTML ve diğer statik kaynaklarınızı kullanıcılara hızlıca ulaştırabilirsiniz.
Dinamik olarak oluşturulmuş web sayfalarının statik olarak cachelenebilmesi için ilgili sayfaların kullanıcılara özel şekilde dinamik yada her istekte içeriği güncellenecek şekilde düzenlenmemesi gereklidir. Her kullanıcı isteği ile içerik yapısı, sayfa içeriği değişen sayfaların statik olarak önbelleklenmesi sağlıklı olmayacaktır.
<