PageSpeed Insights veya Lighthouse raporunda görülen “Verimli önbellek sürelerini kullanın” uyarısı, sitenizdeki bazı statik dosyaların tarayıcı tarafından yeterince uzun süre saklanmadığını gösterir. Bu durum, kullanıcı siteyi ikinci kez ziyaret ettiğinde tarayıcının daha önce indirdiği dosyaları yeniden istemesine neden olur. Sonuç olarak tekrar ziyaretlerde sayfa gereksiz yere yavaşlar. Chrome geliştirici dokümantasyonuna göre bu uyarı, tekrar ziyaretlerde gereksiz indirmelere yol açan yetersiz önbellek politikalarını tespit eder.
Bu hata neden önemlidir?
Tarayıcı önbelleği doğru yapılandırıldığında kullanıcı daha önce indirilen CSS, JavaScript, görsel, font ve benzeri statik dosyaları yeniden ağ üzerinden almak zorunda kalmaz. Bu da özellikle tekrar ziyaretlerde sayfa açılışını hızlandırır. Google’ın Lighthouse dokümanında da belirtildiği gibi uzun önbellek ömrü, tekrar ziyaret performansını iyileştirir.
Üstelik web performansında sadece dosya boyutu değil, ağ gecikmesi de çok önemlidir. İstek sayısı azaldıkça kullanıcı deneyimi genellikle daha akıcı hâle gelir. Bu yüzden önbellek stratejisi yalnızca “sunucu yükünü azaltmak” için değil, doğrudan kullanıcı deneyimini iyileştirmek için de kritik bir optimizasyondur.
“Verimli önbellek sürelerini kullanın” hatası tam olarak neyi işaret eder?
Bu uyarı çoğunlukla şu durumlardan kaynaklanır:
- CSS ve JavaScript dosyalarında kısa max-age kullanılması
- Görsellerin önbellek süresinin çok kısa olması
- Font dosyalarının hiç önbelleğe alınmaması
- Üçüncü taraf kaynakların düşük TTL ile gelmesi
- Sürümleme yapılmadığı için uzun önbellek süresi verilememesi
Lighthouse, özellikle statik varlıklarda uzun süreli önbellekleme önerir. Web.dev dökümantasyonu, değişmez statik dosyalar için 1 yıl veya daha uzun süreli önbellekleme kullanılmasını; bunun için de Cache-Control: max-age=31536000 gibi bir başlık atanmasını önerir. Aynı doküman, dosya güncellemelerinde sorun yaşamamak için dosya adına hash eklenmesini tavsiye eder.
Bu hata hangi dosyalarda daha sık görülür?
En sık şu kaynak türlerinde karşılaşırım:
- .css
- .js
- .webp, .jpg, .png, .svg
- .woff, .woff2
- statik tema veya eklenti dosyaları
- CDN üzerinden servis edilen eski sürüm dosyalar
Özellikle WordPress sitelerde tema, eklenti ve üçüncü taraf script dosyaları bu uyarının ana sebebi olur. Teknik olarak sorun çoğu zaman dosyanın kendisi değil, o dosyaya dönen HTTP yanıt başlıklarıdır.
Temel çözüm mantığı nedir?
Çözümün özü şudur:
Sık değişmeyen statik dosyalara uzun önbellek süresi verilir, sık değişen HTML belgeleri ise uzun süre önbellekte tutulmaz.
Buradaki en kritik ayrım budur. Web.dev rehberleri, gezinti isteğiyle gelen HTML çıktılarında uzun süreli cache kullanılmaması gerektiğini, bunların genellikle ağ üzerinden taze olarak doğrulanmasının daha doğru olduğunu belirtir. Buna karşılık sürümlenmiş statik dosyalarda uzun ömürlü cache çok doğru bir yaklaşımdır.
Doğru önbellek stratejisi nasıl olmalı?
1) Statik dosyalarda uzun süreli cache kullanın
CSS, JS, font ve görseller için, dosya adı sürümleniyorsa şu yaklaşım idealdir:
Cache-Control: public, max-age=31536000, immutable
MDN’ye göre max-age kaynağın saniye cinsinden ne kadar süre taze kabul edileceğini belirtir. Yine MDN, önbellek kırma yani sürümlenmiş dosya adı kullanıldığında immutable direktifinin yeniden doğrulamayı azaltmak için eklenebileceğini söyler.
2) Dosyaları sürümlere ayırın
Uzun cache süresi verip dosya adını sabit bırakırsanız kullanıcı eski dosyayı görmeye devam edebilir. Bu yüzden dosya adı değişmelidir:
- app.css yerine app.3f4a91.css
- main.js yerine main.a92d10.js
Web.dev, uzun süreli cache kullanırken dosya adında hash bulunmasının en güvenli yöntem olduğunu açıkça önerir.
3) HTML için farklı politika uygulayın
Ana HTML belgesi için çoğu projede aşağıdaki yaklaşım daha uygundur:
Cache-Control: no-cache
Buradaki amaç “hiç cache olmasın” değildir; tarayıcının her ziyarette güncel sürümü doğrulamasıdır. Web.dev, HTML navigasyon yanıtlarında uzun süreli Cache-Control başlıklarının genel kural olarak tercih edilmemesi gerektiğini belirtir.
Sunucu tarafında nasıl uygulanır?
Apache (.htaccess) örneği
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(css|js|webp|svg|jpg|jpeg|png|gif|woff|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
<FilesMatch "\.(html|php)$">
Header set Cache-Control "no-cache"
</FilesMatch>
</IfModule>
Nginx örneği
location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|woff|woff2)$ {
expires 1y;
add_header Cache-Control "public, max-age=31536000, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache";
}
CDN kullanıyorsanız nelere dikkat etmelisiniz?
Birçok sitede asıl sorun origin sunucuda değil, CDN katmanında olur. Sunucuda doğru başlıklar tanımlanmış olsa bile CDN eski ya da kısa TTL politikası uygulayabilir. Bu nedenle şu üç noktayı kontrol etmek gerekir:
- Origin response header gerçekten doğru dönüyor mu?
- CDN bu header’ı ezip değiştiriyor mu?
- Edge cache ile browser cache birbirine karıştırılıyor mu?
Bu ayrım çok önemlidir. Kullanıcının tarayıcı önbelleği ile CDN edge önbelleği aynı şey değildir. PageSpeed’in gördüğü hata çoğu zaman browser cache tarafıyla ilgilidir.
Üçüncü taraf kaynaklar neden bu hatayı büyütür?
Bazen sitenizdeki dosyalar doğru ayarlanmıştır ama yine de raporda hata görünür. Bunun nedeni üçüncü taraf servislerdir. Reklam script’leri, canlı destek araçları, harita bileşenleri, takip kodları veya harici widget’lar kısa önbellek ömrüyle gelebilir. Bu durumda her zaman tam kontrol sizde olmaz.
Böyle senaryolarda yapılabilecekler şunlardır:
- Kullanılmayan üçüncü taraf script’leri kaldırmak
- Tekrarlayan servisleri azaltmak
- Mümkünse yerel barındırma yapmak
- Kritik olmayan üçüncü taraf kaynakları gecikmeli yüklemek
Ben bu hatayı sahada nasıl çözdüm?
Geçen yıl bir e-ticaret projesinde PageSpeed raporunda sürekli “Verimli önbellek sürelerini kullanın” uyarısı çıkıyordu. İlk bakışta sorun görseller gibi görünüyordu ama ayrıntılı incelemede esas problemin tema dosyaları ve fontlar olduğunu gördüm. CSS ve JS dosyaları her sayfada aynı kalmasına rağmen sadece birkaç saatlik cache süresiyle servis ediliyordu. Üstelik dosya adlarında sürüm hash’i yoktu.
İlk aşamada şu düzenlemeleri yaptım:
- Tema CSS ve JS dosyalarını build sürecine aldım.
- Dosya adlarına hash ekledim.
- Statik dosyalara public, max-age=31536000, immutable tanımladım.
- HTML belgelerini no-cache ile bıraktım.
- CDN üzerinde browser cache ayarlarının origin header’ı ezmesini engelledim.
- Font dosyalarını da uzun ömürlü cache kapsamına aldım.
Sonuçta tekrar ziyaretlerde ağ isteği sayısı ciddi biçimde düştü. En önemlisi de kullanıcıların kategori ve ürün sayfaları arasında dolaşırken yaşadığı “yeniden yükleniyor hissi” belirgin şekilde azaldı. Teknik olarak tek bir sihirli dokunuş yoktu; asıl farkı oluşturan şey, HTML ile statik varlıkları aynı cache mantığıyla yönetmeyi bırakmak oldu.
En sık yapılan hatalar
Bu konuda en çok gördüğüm yanlışlar şunlardır:
- HTML’ye 1 yıl cache vermek: Bu, içerik güncellemelerini bozabilir. HTML ile statik dosyaları aynı kefeye koymamak gerekir.
- Uzun cache verip dosya sürümleme yapmamak: Bu durumda kullanıcı eski CSS veya JS dosyasını görmeye devam edebilir. Uzun cache ile hash’li dosya adı birlikte kullanılmalıdır.
- Sadece Expires kullanmak: MDN’ye göre Cache-Control: max-age, modern kullanımda öncelikli mekanizmadır; her ikisi varsa max-age tercih edilir.
- Sadece sunucuyu kontrol etmek: Bazen asıl problem CDN, reverse proxy veya üçüncü taraf sağlayıcı tarafındadır.
Bu hata tamamen sıfırlanmalı mı?
Hayır, her zaman değil. Özellikle üçüncü taraf kaynaklar kullanıyorsanız raporda kalan bazı öğeler sizin doğrudan kontrolünüz dışında olabilir. Burada amaç, kendi yönettiğiniz tüm statik kaynaklarda doğru önbellek politikasını uygulamaktır.
Ayrıca her kaynağa körü körüne 1 yıl önbellek vermek de doğru bir yöntem değildir. Değişim sıklığına göre akıllı ayrım yapmak gerekir.
