Nuxt SWR önbelleğlemesi bir ziyaretçinin çerez ve içeriğini diğer kullanıcılara geri oynatabiliyor, dev.to yazısı gösteriyor

Tek önbellek anahtarı, çok ziyaretçi

Nuxt'ta stale-while-revalidate önbelleğlemesini etkinleştirmek tek satırlık bir routeRules yapılandırması gerektirir — bir rota desenine swr: 60 eklemek — ve Muhammad Usama'nın bir dev.to yazısına göre time-to-first-byte süresini saniyelerden milisaniyelere indirebiliyor. Sorun mimaride: önbelleğe alınan yanıt tek bir istek için bir kez üretilir ve ardından aynı önbellek anahtarına denk gelen her sonraki isteğe iletilir. Kişiselleştirilmiş bir sitede, bir ziyaretçinin verisi başka bir ziyaretçinin tarayıcısına böyle düşer.

Yazar, bu sorunlarla ilk kez büyük bir e-ticaret vitrini önbelleğe alırken karşılaştığını, sonra davranışın production kurulumuna özgü bir artefakt değil gerçek olduğunu doğrulamak için her senaryoyu Nuxt 4.5.2 ve Nitro 2.13.4 çalıştıran minimal bir uygulamada yeniden kurduğunu yazıyor.

Tuzak 1: render sırasında ayarlanan çerezler geri oynatılıyor

İlk yeniden üretim, useCookie ile sunucu tarafı render sırasında bir A/B test kovası atayan sayfa. Rota üzerinde önbelleğleme etkinken, üç yeni ziyaretçi de aynı Set-Cookie başlığını aldı — ilk render için üretilen kova değeri, önbelleğe alınmış kayda gelen herkese geri oynatıldı. Yazıda açıklandığı gibi, Set-Cookie başlığı önbelleğe alınmış yanıtla birlikte saklanıyor, dolayısıyla deneyin tamamı tek bir kovaya çöküyor.

Bu tezat, çözüme işaret ediyor: server middleware içinde ayarlanan aynı tür çerez önbelleğe alınmadı, çünkü middleware her istekte önbelleğe bakılmadan önce çalışıyor. Öneri, ziyaretçiye özel çerezleri sayfa, component veya plugin yerine server/middleware içinde ayarlamak ve çerezi yalnızca değer gerçekten değiştiğinde yazmak.

Tuzak 2: birden fazla host tek kaydı paylaşıyor

İkinci tuzak, tek bir uygulamanın birkaç hosta hizmet verdiği dağıtımları etkiliyor — ayrı mağazalar, kiracılar veya ülke alan adları. Varsayılan önbellek anahtarı yol tabanlı olduğundan, önce render eden host kazanır: yazarın laboratuvarında her iki test mağazası da ilk render tarafından yakalanan host değerini aldı. Doğruladığı çözüm, rota kuralına cache: { varies: ['host', 'x-forwarded-host'] } eklemek; bu, istekler önbelleğe uğrarkan her hosta kendi önbellek kaydını veriyor.

Tuzak 3: kişiselleştirilmiş içerik HTML'e donduruluyor

Üçüncü yeniden üretim, SSR sırasında bir para birimi çerezi okuyan sayfa. EUR ve PKR çerezleri gönderen ziyaretçilerin ikisi de ilk, çerezsiz render tarafından işlenmiş para birimini aldı. Yazı çözümleri sıralıyor: kişiselleştirilmiş arayüzü sunucu renderından tamamen uzak tutup ClientOnly veya istemci tarafı fetch kullanmak; nötr bir değer render edip istemcide düzeltmek; önbellek anahtarını yalnızca küçük ve sınırlı bir değer kümesi boyunca değiştirmek — asla ziyaretçiye özel bir çerezle değil; ya da rotayı önbelleğe almamak. Yazar, fiyatlar ayrıca deneylere veya segmentlere bağlıysa yalnızca para birimini kontrol etmenin her durumu yakalamayacağı konusunda uyarıyor.

curl ile hızlı bir denetim

Yazıda mevcut bir site için ucuz bir test de anlatılıyor: önbelleğe alınmış bir rotayı iki farklı yeni ziyaretçi olarak iki kez isteyin ve Set-Cookie başlıklarını blok olarak değil tek tek karşılaştırın, çünkü middleware tarafından meşru şekilde verilen taze bir çerez, geri oynatılan bir çerezin yanında durabilir. Her iki istekte de aynı değeri taşıyan herhangi bir çerez önbellekten geliyordur.

Neden önemli

Rota düzeyinde SWR önbelleğlemesi Nuxt'taki en kolay performans kazanımlarından biri ve bu erişilebilirlik tam da riskin kendisi. Hata modu sessiz ve aralıklı — yalnızca önbellek penceresi içindeki sonraki ziyaretçilerde ortaya çıkıyor — bu yüzden tek kullanıcılı testte asla görünmüyor. Geri oynatılan bir Set-Cookie başlığı bir A/B testini sessizce tek kovaya çözebilir veya oturum benzeri bir çerezle bir ziyaretçinin durumunu diğerine açığa çıkarabilir. Çok kiracılı bir uygulamada yalnızca yola dayalı önbellek anahtarı yanlış mağazanın içeriğini ve fiyatlarını sunabilir. Bu yazıyı yararlı kılan şey, her tuzağın minimal bir uygulamada yeniden üretilebilir olması, her birinin somut bir çözümünün olması ve denetimin bugün staging'e karşı çalıştırılabilecek iki komutluk bir curl kontrolü olması. Yazar toplamda yedi tuzak belgelediğini söylüyor — revalidation sırasında bir ERR_HTTP_HEADERS_SENT hatası, istemci gezinmesi sırasında durum sızıntısı, süreç başına önbellek depolaması ve CLS ölçüm hataları dahil — yanı sıra bir laboratuvar uygulaması, bir sızıntı testi betiği ve depo taramalı bir denetim komutu da paylaşıyor.