Bayat Cloudflare Pages deploy'ları s-maxage'e bağlandı, ayrıca faturayı şişiren Workers ürünleri

dev.to'daki iki yeni yazı Cloudflare'i iki zıt yönden ele alıyor: biri Production olarak işaretlenmiş ama başarı bildirdiği hâlde dünün HTML'ini sunmaya devam eden bir Cloudflare Pages deploy'ını incelerken, diğer platformun 5 dolarlık Workers planından paranın tam olarak nerede sızdığını haritalıyor. İkisi de aynı derse varıyor: varsayılanlar sessiz, override'lar daha da sessiz.

Başarılı olan ama hiçbir şeyi değiştirmeyen deploy

İlk dev.to gönderisine göre yeni bir Pages deploy'ı Production olarak işaretlenmiş ve Success göstermiş, ama hem özel alan adı hem de projenin pages.dev host adı bir günden uzun süre önceki index.html'i sunmuş. Yanıt başlıkları durumu açıklıyordu: cf-cache-status: HIT, yaklaşık 30 saatlik bir age ve cache-control: public, s-maxage=604800. Farklı content hash'leriyle yapılan iki yeniden deploy da hiçbir şeyi değiştirmedi, çünkü edge'e bu HTML'i bir hafta tutabileceği söylenmişti.

Yazara göre cache'lenebilir asset'ler için Pages varsayılanı public, max-age=0, must-revalidate şeklinde ve Pages kendi başına asla s-maxage eklemez. Dolayısıyla bir haftalık paylaşılan cache ömrü projenin kendisinden gelmek zorunda: bir _headers kuralı, bir Pages Function ya da advanced-mode bir worker.

Başlık nerede gizleniyor

Olağan kaynak, performans rehberlerinden kopyalanan ve HTML dahil her yolu eşleştiren catch-all bir _headers kuralı. Gönderi, framework'ler public/ klasörünü build çıktısına kopyaladığı için kaynağın yanı sıra build çıktısında da arama yapılmasını öneriyor. Ayrıca bir uyarı da içeriyor: _headers kuralları Pages Functions tarafından üretilen yanıtlara uygulanmaz, dolayısıyla sayfayı bir SSR framework'ü veya bir worker dosyası render ediyorsa başlık o kodun kendi Response'unda ayarlanıyor demektir.

Purge çoğunlukla bir seçenek değil

Rahatsız edici kısım burası. Belgelenen purge yolu bir zone'un cache ayarlarından geçiyor ve özel alan adı başka bir DNS sağlayıcısında yaşayan pages.dev üzerindeki bir projenin purge'lanacak bir zone'u yok. Gönderinin atıf yaptığı Cloudflare belgelerine göre asset'ler veri merkezi başına, bir haftalık TTL ile cache'leniyor ve eski asset'ler bir deploy'dan sonra bir haftaya kadar kalabiliyor.

Çözüm katı bir sırayla iki adımdan oluşuyor: önce HTML üzerinde s-maxage ayarlayan her neyse onu kaldırıp deploy edin, aksi hâlde her deploy taze bir yedi günlük sayaç başlatır; sonra zaten cache'lenmiş kopyaların geçmesini bekleyin. Purge Everything kendi zone'unuzdaki bir özel alan adını temizler, ama pages.dev host adı retention süresi dolana kadar bayat kalabilir. Bu arada yazar, yeni build'i hash tabanlı deployment URL'sinde kontrol etmeyi öneriyor; o URL tam olarak o build'e sabitlenir ve production cache'ini paylaşmamalı, ancak yazar bu son kısmı doğrulamamış.

Aynı belirti, temiz başlıklarla da ortaya çıkabilir; özel alan adındaki bir Cache Rule her şeye veya kök yola bir Edge TTL ayarlıyorsa. Gönderiye göre uzun cache ömürleri yalnızca fingerprint'lenmiş dosyalar için güvenli; Vite ve Astro gibi bundler'lar zaten asset adlarına hash koyuyor, bu yüzden kaçınılacak tek kural HTML'i de kapsayan catch-all bir kural.

5 dolarlık plan para nereden sızdırıyor

İkinci dev.to gönderisi ayda 5 dolarlık Workers Paid planını ayrıştırıyor: plan 10 milyon istek ve 30 milyon CPU milisaniyesi içeriyor, aşım ise milyon istek başına 0,30 dolar ve milyon CPU ms başına 0,02 dolar. Bant genişliği ücretlendirilmiyor. İnsanları şaşırtan faturalar, yazarın dediğine göre, sahiplerinin farkından çok daha fazla iş yapan birkaç üründen geliyor.

Queues mesaj başına üç işlem faturalandırıyor (bir yazma, bir okuma, bir silme), dolayısıyla batching verimliliği artırıyor ama faturayı değil ve her retry bir okuma ekliyor. KV yazmaları okumaların kabaca on katı maliyetlidir (dahil edilen milyon yazmanın ötesinde milyon başına 5,00 dolar, okumada 0,50 dolar), bu yüzden her istekte güncellenen ve ayda 5 milyon yazma yapan bir sayaç yalnızca yazmalarda yaklaşık 20 dolar demek. D1 dönen satır değil taranan satır üzerinden faturalandırıyor; yani indekslenmemiş bir kolondaki filtre üç satır döndürmek için bütün tabloyu tarayabiliyor. Durable Objects o belleği kullanıp kullanmadığına bakılmaksızın 128 MB üzerinden faturalandırılıyor, Hibernation API olmadan WebSocket bağlantıları bağlantının tamamı için faturalandırılıyor ve bekleyen I/O bir nesneyi faturalanabilir şekilde 15 dakikaya kadar bellekte tutabiliyor.

Diğer yandan en büyük Workers AI israfı, sonuçları cache'lemek yerine her seferinde aynı girdiyle bir model çağırmak; Vectorize'ın sorgu maliyeti dönen sonuçlarla değil depolanan vektör sayısıyla ölçekleniyor; Browser Rendering ayda 10 saat içeriyor ve sonrasında saat başına 0,09 dolar, bu yüzden kapatılmayan oturumlar birikiyor. R2, kod her istekte HeadObject veya ListObjects çağırmadığı sürece ucuz kalıyor; öyle bir durumda metadata D1'e veya KV'ye ait.

Neden önemli

İki yazı da aynı hata modunu tarif ediyor: görünmez bir ayar sessizce "doğru"nun ne demek olduğunu yeniden tanımlarken altyapının doğru davranması. Pages'te kopyalanmış tek bir başlık her deploy'ı iptal düğmesi olmayan bir haftalık rollout'a çeviriyor. Workers'ta cömert kotalar, faturalandırma biriminin (mesajlar, yazmalar, taranan satırlar, GB-saniye, depolanan vektörler) geliştiricilerin muhakeme ettiği birim olmadığı ürünleri gizliyor. Pratik savunmalar örtüşüyor: üçüncü kez deploy etmeden önce yanıt başlıklarını okuyun, lansmandan önce istek başına işlem sayısını sayın ve her şeyden önce fatura uyarılarını açın.