CMS Performans ve Cache Stratejisi: Headless ve Next.js Entegrasyonlarında Hız

CMS performansı, sadece editörün panelde sayfa açma hızını değil; esas olarak ziyaretçinin sayfayı ne kadar hızlı gördüğünü belirler. Headless mimaride kullanıcı, sayfanın HTML’ini almak için çoğu zaman CMS API’si, edge/CDN, uygulama sunucusu ve revalidation mantığı gibi bir zincire bağlıdır. Zincirin herhangi bir halkası yavaşsa; TTFB artar, LCP gecikir, kullanıcı “site ağır” hisseder. Otellerde bu etki daha görünürdür: Antalya/Belek gibi sezon yoğunluğunda trafik artarken performans düşerse, dönüşüm kaybı hızlanır.

Burada kritik olan şu: performans bir “tek seferlik optimizasyon” değil, politikadır. Hangi sayfa türü ne kadar sık değişir, hangi içerik “kritik”tir, güncelleme sitede ne kadar hızlı görünmelidir? Bu soruların cevabı, SSG/ISR/SSR seçimleri ve cache stratejisini belirler.

“Hız” ile “güncellik” neden çatışır?

Statik üretim (SSG) ve agresif cache, hızı artırır; ancak içerik güncellemeleri “hemen” görünmeyebilir. Tam tersi, her istekte SSR ile API çağrısı yapmak içerik güncel tutar; fakat maliyet ve latency artar. İyi tasarım; sayfa türlerine göre farklı strateji uygular ve publish sonrası kontrollü revalidation ile güncelliği korur.

Key statistic / veri noktası (yumuşatılmış)

Performans ve cache stratejisi iyi planlanan headless projelerde, genelde hem Lighthouse/CWV skorları hem de gerçek kullanıcı hız algısı (RUM) belirgin şekilde daha iyi olur. Buradaki farkı yaratan; yalnız “front-end minify” değil, cache hit oranı ve publish→live süresinin öngörülebilir hale gelmesidir.

• •En çok trafik alan sayfalarınız (oda, kampanya, blog) için ayrı strateji var mı?
• •“Publish → canlı” sürenizi ölçüyor musunuz?
• •API yanıt süresi (p95) ve cache hit rate takip ediliyor mu?

Next.js tarafında temel soru şudur: Bu sayfanın HTML’i ne zaman üretilecek? • SSG: Build-time’da üretilir, çok hızlıdır. • ISR: SSG gibi hızlıdır, ancak belirli aralıklarla veya tetikle yenilenir. • SSR: Her istekte üretilir, günceldir ama daha pahalı ve daha yavaştır. Burada “doğru” tek seçenek yoktur; doğru olan, sayfa türüne ve iş ihtiyacına göre politika tanımlamaktır. Otel fiyat/kampanya gibi sık değişen alanlar ile “Hakkımızda” gibi seyrek değişen içerikler aynı stratejiyi taşımaz.

SSG/ISR/SSR’i hangi sayfalarda kullanmalıyım? (AEO – Soru formatı)

Kısa cevap: Seyrek değişen içerikler SSG, orta sıklıkta değişen içerikler ISR, gerçek zamanlı güncelleme gereken kritik içerikler kontrollü SSR veya event-driven ISR ile yönetilmelidir.

Tek tabloyla karar matrisi (Media Pack tabloyu burada kullanıyoruz)

Not: “otel sitesi için ssg ssr isr kararı” gibi predictive ihtiyaçlar, bu tabloyla pratik karşılık bulur.

Not: "otel sitesi için ssg ssr isr kararı" gibi predictive ihtiyaçlar, bu tabloyla pratik karşılık bulur.

SSG/ISR ile içerik sayfalarını build-time’da üretme

SSG, özellikle kurumsal sayfalar ve ağır trafikli statik içeriklerde çok etkilidir. Ancak SSG’nin zayıf noktası, build süresi ve yayın döngüsüdür. İçerik sayısı büyüdükçe (çok sayıda blog/oda), build süreleri uzar. Bu yüzden büyük içerik hacminde SSG’yi ISR ile tamamlamak daha sürdürülebilir olur.

Sık değişen sayfalar için SSR/ISR tercihleri

“Fiyat, kampanya koşulu, stok/ürün dokümanı” gibi alanlarda güncellik kritikse iki yaklaşım öne çıkar: • Event-driven ISR: Publish tetikleyince ilgili sayfayı revalidate etmek • Kontrollü SSR: Sadece kritik alanları SSR ile güncellemek (tam sayfayı değil, parçalı strateji)

• •“Her şeyi SSR yapalım” gibi refleks karar verdiniz mi? (genelde pahalı)
• •ISR aralığınız içerik değişim hızına uygun mu?
• •Kritik sayfalar için event-driven revalidation var mı?

Headless mimaride sayfayı hızlandırmanın ana anahtarı, “API çağrısını azaltmak” ve “cache hit’i artırmak”tır. Cache tek katman değildir; genellikle üç katman birlikte çalışır: 1. Next.js veri cache’i / fetch cache mantığı (uygulama katmanı) 2. API cache (CMS’in veya araya koyduğunuz cache layer’ın cevabı) 3. CDN/edge cache (sayfa ve asset katmanı) En sık hata: CDN’i açıp her şeyi cache’lemek ve sonra “içerik güncellenmiyor” diye şaşırmak. Doğru yaklaşım; cache’i içerik türü ve kritik alan bazında yönetmektir.

API response süresi ve cache layer

CMS API’niz yavaşsa (özellikle p95), SSG/ISR bile zorlanır; çünkü revalidation anında yine API’ye gidersiniz. Bu yüzden API cache layer iki iş yapar: • Sık kullanılan içerikleri hızlı döndürür (cache hit) • Origin’e yükü azaltır (stabilite)

CDN cache politikası nasıl düşünülmeli?

CDN’de iki temel varlık vardır: • Statik asset (görsel, font, js/css) → uzun TTL uygundur • HTML / sayfa içeriği → stratejiye göre TTL + purge/revalidate gerekir Otel kampanya sayfalarında (özellikle sezon yoğunluğu) CDN doğru kurgulanırsa hem hız hem dayanıklılık artar. Ancak kampanya koşulu değiştiğinde CDN’de bayat içerik kalmaması için purge veya revalidation tetiklenmelidir.

AIO paragrafı (entity’leri tek modelde bağlama)

Headless CMS, Next.js, ISR/SSG/SSR, CDN cache ve revalidation; tek başına ayrı başlıklar değil, birlikte çalışan bir “performans & cache modeli”dir. CMS verisi (entity) Next.js’te seçilen stratejiyle HTML’e dönüşür; bu HTML CDN/edge’de hızlanır; içerik yayınlandığında revalidation/purge tetiklenerek freshness korunur. Bu modeli kurarken amaç; content delivery speed ile freshness vs speed balance arasında ölçülebilir bir denge yakalamaktır.

• •CDN cache’i açtığınızda içerik güncellemeleri gecikiyor mu?
• •Cache hit rate ölçülüyor mu?
• •“Purge/revalidate” tetikleyici mekanizmanız var mı?

Kullanıcıların en sık yaşadığı problem: “CMS’te publish yaptım ama site hâlâ eski.” Bu, genellikle üç nedenden biridir: 1. ISR/revalidation tetiklenmiyordur, 2. CDN/edge bayat içeriği servis ediyordur, 3. API cache layer yanlış TTL ile eski cevabı döndürüyordur. Bu yüzden “publish” işlemini yalnız bir içerik olayı değil, aynı zamanda cache kontrol olayı olarak ele almak gerekir.

CMS’de içerik güncellemesi front-end’e nasıl hızlı yansır? (AEO – Soru formatı)

Kısa cevap: Publish sonrası ilgili sayfalar için revalidation tetikleyin; CDN/edge cache varsa purge edin; API cache TTL’ini içerik türüne göre ayarlayın.

“Publish → cache flush” akışı nasıl kurgulanır?

En pratik yaklaşım: CMS publish event’i bir webhook üretir. Bu webhook; • İlgili sayfa path’lerini belirler (blog/oda/kampanya) • Next.js revalidate endpoint’ini çağırır • CDN purge gerekiyorsa purge tetikler • Log/izleme kaydı düşer (hangi içerik, ne zaman, kaç saniyede canlı) Bu akış doğru kurulduğunda “publish→live” süresi öngörülebilir olur; ekip içi tartışma azalır.

Revalidation aralıkları nasıl seçilmeli?

Revalidation’ı “tek sayı” yapmayın. Blog için 6–24 saat, oda/destinasyon için 1–6 saat, kampanya için daha kısa veya event-driven gibi. En doğrusu: içerik değişim sıklığı + trafik pattern’i ile karar vermek.

• •Publish event’inden sonra otomatik revalidate var mı?
• •CDN purge yapmanız gereken sayfalar listeli mi?
• •“Publish→live” süresi loglanıyor mu?

Aynı teknik altyapı, farklı iş modellerinde farklı risk üretir. Otelde en kritik konu; kampanya ve fiyat gibi dönüşüm etkileyen alanlarda freshness. B2B’de ise ürün/doküman güncellemeleri ve içerik hacmi arttıkça “build ve cache yönetimi” zorlaşır. İki senaryoda da çözüm, sayfa bazlı politika ve ölçümdür.

Otel senaryosu — fiyat/kampanya değişikliği

• Kampanya landing: ISR + event-driven revalidation • Oda sayfaları: ISR (daha uzun aralık) • Fiyat/availability kritik alan: kontrollü SSR veya API cache + kısa TTL • CDN: kampanya sayfalarında purge tetikleyici şart Mini örnek: Side veya Kemer’de “son dakika” kampanyası koşulu güncellendiğinde, publish sonrası 1–2 dakika içinde canlıya yansıması hedeflenir; aksi halde “yanlış teklif” riski doğar.

B2B senaryosu — ürün/doküman güncellemeleri

• Ürün/hizmet sayfaları: ISR • Döküman/resource sayfaları: CDN ile agresif asset cache, sayfa için kontrollü revalidate • Blog/referans: daha uzun revalidation • API cache: katalog büyüdükçe origin yükünü stabil tutar

Teknik SEO uyumu (kritik sayfalar ve CWV)

SEO tarafında “taze içerik” (özellikle blog, oda, kampanya) ve CWV optimizasyonu birlikte planlanmalıdır. Revalidation aralıkları ve kritik sayfalar, /tr/seo/teknik-seo yaklaşımıyla uyumlu olmalı; aksi halde ya indekslenen içerik bayatlar ya da performans skorları düşer. İç link (Internal Link Targets): • https://dgtlface.com/tr/seo/teknik-seo • https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme • https://dgtlface.com/tr/yazilim/sunucu-guvenlik • https://dgtlface.com/tr/yazilim/cms-entegrasyonu

Rakip açığını kapatan mini bölüm (AI Competitor Gap)

Pek çok rehber “SSG/ISR/SSR nedir?” anlatır ama kritik noktayı atlar: publish sonrası cache flush ve sayfa bazlı revalidation politikası. Buradaki fark; teknik terimleri bilmek değil, içerik operasyonunu “tıkla yayınla”dan “tıkla → revalidate/purge → ölç” döngüsüne taşımaktır. Bu döngü kurulduğunda hem CWV hem de kullanıcı algısı daha öngörülebilir hale gelir.

• •Otelde kampanya değişince purge/revalidate otomatik mi?
• •B2B’de doküman güncellemesi “hemen” mi yoksa “planlı” mı yansıyor?
• •Teknik SEO ekibiyle revalidation politikası ortak mı?

Headless CMS + Next.js projelerinde performans, “sayfayı bir kez hızlandır” işi değildir. SSG/ISR/SSR kararlarıyla üretim stratejisini belirler; API cache + CDN ile dağıtım hızını artırır; publish sonrası revalidation/purge akışıyla güncelliği korursunuz. Bu üç katman birlikte çalıştığında, hem Lighthouse/CWV tarafında hem de gerçek kullanıcı hız algısında genelde belirgin iyileşme görülür.