Web Programlama Eğitimi: Tarayıcı Cache ve HTTP Doğrulama

Web Programlama Eğitimi İçin Cache Davranışını Ölçerek Başlatın

Cache politikasını değiştirmeden önce Chrome DevTools > Network ekranında aynı sayfayı iki kez yükleyin; ilk ve ikinci istekte Size, Transferred, Status ve Cache-Control sütunlarını kaydedin. İkinci yüklemede JavaScript paketi hâlâ 200 ile ağdan indiriliyorsa sorun çoğu zaman bundle boyutu değil, yanıtta uzun ömürlü bir cache yönergesinin bulunmamasıdır. Tarayıcıdaki cache etkisini ayırmak için DevTools'ta “Disable cache” seçeneğinin yalnızca DevTools açıkken geçerli olduğunu da dikkate alın.

Sunucunun gerçekten ne döndürdüğünü tarayıcıdan bağımsız doğrulamak için aşağıdaki komutları kullanın. İlk komut cache direktiflerini ve ETag değerini alır; ikinci komut koşullu istekte 304 bekler. 304 yanıtında gövde taşınmaz, ancak tarayıcı önbellekteki temsilin hâlâ geçerli olduğunu bilir.

curl -sI https://app.example.com/assets/app.8e1c2a.js
# Cache-Control: public, max-age=31536000, immutable
# ETag: "8e1c2a"

curl -sI   -H 'If-None-Match: "8e1c2a"'   https://app.example.com/assets/app.8e1c2a.js
# HTTP/2 304

Frontend development eğitimi sırasında sık görülen hata, Lighthouse skorunu cache doğrulaması yerine kullanmaktır. Lighthouse çoğunlukla kontrollü, soğuk bir profil üretir; tekrar ziyaret maliyetini ölçmek için WebPageTest'te iki “repeat view” çalıştırması açın veya Chrome Performance panelinde ikinci navigasyonda ağ aktivitesini inceleyin. Değişiklikten önce ve sonra aynı ağ profili, aynı URL ve aynı tarayıcı profiliyle karşılaştırma yapın; aksi hâlde CDN POP değişimi veya sıcak disk cache sonucu yanıltır.

Fingerprint'li Varlıklarda Immutable Cache: Frontend Framework Karşılaştırması

React, Angular ve Vue tabanlı derlemeler dosya adına içerik özeti ekleyebilir. Bu özellik, app.8e1c2a.js değiştiğinde URL'nin de değişmesini sağlar; dolayısıyla eski URL'ye bir yıl cache vermek güvenlidir. Buna karşılık /assets/app.js gibi sabit isimli bir dosyaya immutable eklemek deploy sonrası kullanıcıların eski kodu çalıştırmasına yol açar. ReactJS eğitimi, Angular eğitimi ve VueJS eğitimi projelerinde build çıktısında hash olup olmadığını doğrudan dist/ veya build/ dizininden kontrol edin.

Nginx'te HTML ile fingerprint'li asset'leri aynı cache kuralına sokmayın. HTML, yeni asset manifest'ini referansladığı için yeniden doğrulanmalı; hash'li JS/CSS ise uzun süre saklanmalıdır. Aşağıdaki konfigürasyon, Vite, Angular CLI veya benzer bir bundler'ın hash üreten çıktıları için uygulanabilir bir ayrımdır.

location ~* \.(js|css|woff2|png|webp|svg)$ {
  try_files $uri =404;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

location = /index.html {
  add_header Cache-Control "no-cache";
}

location / {
  try_files $uri $uri/ /index.html;
}

Bu ayrım frontend framework karşılaştırması yaparken framework'ün render modelinden daha temel bir operasyonel farkı ortaya çıkarır: React, Angular veya Vue'nun ürettiği dosya adları değil, CDN'in HTML ve asset için uyguladığı kurallar tekrar ziyaret süresini belirler. Cloudflare, Fastly veya Nginx önünde bir CDN varsa response header'larını hem origin hem edge üzerinden ölçün; örneğin Age başlığı edge hit'i, CF-Cache-Status ise Cloudflare kararını gösterebilir. Origin'de doğru header olup CDN'de yoksa CDN cache rule'ı yanıtı override ediyor olabilir.

API Yanıtlarında ETag ve 304: JavaScript Eğitimi İçin Uygulanabilir Desen

Kullanıcıya göre değişen JSON yanıtlarında bir yıllık max-age yerine ETag ile doğrulama kullanın. ETag, temsilin içerik sürümüdür: istemci If-None-Match ile önceki etiketi yollar; veri aynıysa API 304 döner. Ancak ETag üretimini JSON.stringify çıktısına doğrudan bağlamak, nesne anahtar sırası veya gereksiz alan değişimleri nedeniyle anlamsız invalidation üretebilir. İstemciye gönderilen DTO'yu sabitleyip onun hash'ini hesaplayın.

Express üzerinde aşağıdaki gibi deterministik bir temsil üretilebilir. Üretimde ETag için hızlı fakat çarpışma riskini değerlendirdiğiniz bir hash yerine kriptografik bir özet tercih edin; örnekteki SHA-256, küçük JSON yanıtları için anlaşılır bir başlangıçtır. Ayrıca kişisel veri içeren yanıtlarda public kullanmayın; paylaşımlı CDN cache'i başka kullanıcıya veri sızdırabilir.

import crypto from "node:crypto";

app.get("/api/projects/:id", async (req, res) => {
  const project = await repo.getVisibleProject(req.user.id, req.params.id);
  const body = JSON.stringify({ id: project.id, name: project.name, updatedAt: project.updatedAt });
  const etag = '"' + crypto.createHash("sha256").update(body).digest("base64url") + '"';

  res.set({ "Cache-Control": "private, no-cache", ETag: etag, Vary: "Authorization" });
  if (req.headers["if-none-match"] === etag) return res.status(304).end();
  res.type("application/json").send(body);
});

JavaScript eğitimi örneklerinde fetch() çağrısına rastgele cache: 'no-store' eklemek yaygın fakat pahalı bir reflextir: tarayıcının HTTP doğrulama mekanizmasını tamamen devre dışı bırakır. Önce Network panelinde yanıtın gerçekten kullanıcıya özel olup olmadığını ve Vary: Authorization gereksinimini doğrulayın. Özellikle gzip/brotli dönüşümü origin veya CDN katmanında yapılıyorsa Vary: Accept-Encoding yokluğu, bazı proxy'lerde yanlış sıkıştırılmış temsillerin paylaşılmasına neden olabilir.

Service Worker Güncellemesi: Eski Bundle ve Chunk Hatalarını Önleme

Service Worker kullanılıyorsa HTTP cache kuralı tek başına yeterli değildir; Service Worker kendi Cache Storage alanından eski HTML'i döndürebilir. Chrome DevTools > Application > Service Workers bölümünde “Update on reload” ile geliştirme sırasında güncelleme döngüsünü görün, ardından Application > Cache Storage altında hangi cache adının hangi dosyayı tuttuğunu kontrol edin. İstemcinin eski HTML'i alıp artık CDN'de olmayan yeni bir lazy chunk istemesi, üretimde görülen ChunkLoadError olaylarının tipik nedenidir.

Workbox ile navigasyon isteklerinde HTML'i cache-first yapmak yerine network-first stratejisi kullanın; ağ başarısızsa son bilinen uygulama kabuğuna dönün. Aşağıdaki yapı, hash'li asset'lerin precache manifest tarafından sürümlenmesini sağlar ve HTML'in deploy sonrası güncel kalma olasılığını yükseltir.

import { registerRoute } from "workbox-routing";
import { NetworkFirst } from "workbox-strategies";

registerRoute(
  ({ request }) => request.mode === "navigate",
  new NetworkFirst({
    cacheName: "html-navigations-v1",
    networkTimeoutSeconds: 3,
    plugins: []
  })
);

React Native eğitimi alan ekipler burada önemli bir sınırı ayırmalıdır: React Native uygulamalarında tarayıcı Service Worker API'si yoktur; iOS/Android ağ cache davranışı kullanılan HTTP istemcisi ve platform katmanına bağlıdır. Buna rağmen release dosyası sürümleme ilkesi aynıdır. Web hedefi olan React Native Web projelerinde Service Worker yalnızca web build'ine eklenmeli, native bundle güncellemesiyle karıştırılmamalıdır.

AngularJS Eğitimi ve Modern SPA'larda Deploy Sonrası Cache Testi

AngularJS eğitimi kapsamında bakım yapılan eski SPA'larda sabit adlı app.js ve agresif proxy cache'i sık görülür. Önce build zincirini değiştiremiyorsanız app.js için Cache-Control: no-cache verin; bu değer dosyayı saklamayı yasaklamaz, her kullanımda origin veya CDN ile doğrulanmasını ister. HTML'e sürüm parametresi eklemek geçici bir çözümdür, fakat query string'i cache key'den atan CDN kurallarında etkisiz kalabileceği için header tabanlı doğrulamayı ayrıca test edin.

Deploy pipeline'ına gerçek bir cache regresyon testi ekleyin. Örneğin Playwright ile önce eski sürümde sayfayı açın, yeni sürümü yayınlayın, aynı browser context ile yeniden yükleyin ve uygulamanın yeni build kimliğini sunduğunu doğrulayın. Bu test, yalnızca HTTP 200 beklemekten daha değerlidir; eski HTML'in yeni olmayan asset manifest'ini işaret etmesi 200 yanıtıyla da gerçekleşebilir.

import { test, expect } from "@playwright/test";

test("deploy sonrası yeni build yüklenir", async ({ page }) => {
  await page.goto("https://staging.example.com/");
  const oldBuild = await page.locator("meta[name='build-id']").getAttribute("content");

  // CI burada yeni image/tag deploy adımını çalıştırır.
  await page.reload({ waitUntil: "networkidle" });

  const newBuild = await page.locator("meta[name='build-id']").getAttribute("content");
  expect(newBuild).not.toBe(oldBuild);
});

Bu senaryoda ölçülebilir kabul kriteri belirleyin: ikinci navigasyonda fingerprint'li JS için aktarılan byte sayısı 0 veya cache kaynaklı olmalı, HTML ise en fazla bir doğrulama isteği üretmeli ve deploydan sonra yeni build-id görünmelidir. Bu yaklaşım, framework seçimi tartışmasından bağımsızdır; ReactJS, Angular, VueJS ve AngularJS uygulamalarında aynı HTTP semantiğini test eder.

Sık Sorulan Sorular

Frontend development eğitimi projelerinde Cache-Control: no-cache ne zaman kullanılmalı?

no-cache, HTML dokümanı veya sabit adlı JavaScript gibi her kullanımda güncelliği doğrulanması gereken kaynaklar için uygundur. Tarayıcı kopyayı saklayabilir fakat yeniden kullanmadan önce ETag veya Last-Modified ile sunucuya sorar. İçerik hash'i taşıyan main.a1b2c3.js gibi URL'lerde ise public, max-age=31536000, immutable kullanın.

ReactJS eğitimi ve VueJS eğitimi projelerinde ChunkLoadError nasıl teşhis edilir?

Hata anında istemcide istenen chunk URL'sini, sayfanın yüklediği HTML build kimliğini ve CDN erişim logundaki HTTP durumunu birlikte kaydedin. HTML eski manifest'i referanslayıp chunk 404 dönüyorsa HTML veya Service Worker cache'i eskidir. Workbox Cache Storage kaydını temizleyerek ve HTML'e Cache-Control: no-cache vererek hipotezi doğrulayın; yalnızca sayfayı otomatik yenilemek kök nedeni çözmez.

Angular eğitimi uygulamasında ETag kullanırken Vary: Authorization gerekli mi?

Yanıt giriş yapan kullanıcıya, rolüne veya tenant'ına göre değişiyorsa gereklidir. Aksi hâlde paylaşımlı bir CDN aynı URL ve ETag ile bir kullanıcının yanıtını diğerine verebilir. Daha güvenli başlangıç ayarı Cache-Control: private, no-cache ve Vary: Authorization kullanmaktır; endpoint gerçekten herkese açık ve aynı temsil dönüyorsa ayrıca CDN cache politikası tasarlanabilir.

React Native eğitimi ile web programlama eğitimi arasındaki cache farkı nedir?

Web uygulamasında HTTP cache, Cache Storage ve Service Worker tarayıcı tarafından yönetilir; DevTools Application paneliyle incelenebilir. React Native'de Service Worker bulunmaz; kullanılan fetch katmanı, platformun URL cache davranışı ve uygulama güncelleme mekanizması ayrı değerlendirilir. Ortak ilke, sürümlenmiş statik dosya URL'leri ile kullanıcıya özel API yanıtlarını farklı cache politikalarına ayırmaktır.