Web sitenizin yükleme hızını artırmak ve kullanıcı deneyimini iyileştirmek için atmanız gereken önemli adımlardan biri, statik kaynaklardan sorgu dizelerini kaldırmak. Bu rehberde, konuyu tamamen anlamanız için gerekli her şeyi bulacaksınız: Sorgu dizelerinin teknik detayları, proxy sunucularıyla ilişkisi, farklı platformlarda nasıl kaldırılacağı ve alternatif çözümler. WordPress kullanıyor olsanız da özel bir site yönetiyor olsanız da, bu bilgiler size somut adımlar sunacak.
Sorgu Dizeleri Nedir ve Neden Sorun Yaratır?
Sorgu dizeleri, URL’lerin sonuna eklenen ve genellikle soru işareti (?) ile başlayan parametrelerdir. “style.css?ver=1.2.3” şeklinde bir dosya yolu gördüğünüzde, “ver=1.2.3” kısmı bir sorgu dizesidir. Bunlar genellikle dosya versiyonlarını belirtmek için kullanılır ve “cache busting” amacıyla eklenir. Yani, bir CSS dosyası güncellendiğinde tarayıcı eski versiyonu kullanmasın diye bu parametreler devreye girer.
Sorgu dizeleri aslında geliştiriciler tarafından oldukça mantıklı bir amaçla kullanılır: dosya versiyonlarını yönetmek. Bir CSS veya JavaScript dosyasını güncellediğinizde, tarayıcıların eski önbelleklenmiş versiyonu kullanmasını istemezsiniz. İşte bu yüzden “style.css?ver=1.2.3” gibi bir yapı kullanılır. Versiyon numarası değiştiğinde, tarayıcı bunu yeni bir dosya olarak algılar ve güncel versiyonu indirir. Ancak burada teknik bir paradoks vardır. Bazı eski proxy sunucuları ve önbellekleme sistemleri, sorgu dizesi içeren URL’leri önbelleğe almama eğilimindedir. Bunun nedeni, sorgu dizelerinin genellikle dinamik içerik için kullanılması ve bu içeriğin her istekte değişebilmesidir. Örneğin, “search.php?q=web+geliştirme” gibi bir URL her farklı arama için farklı sonuçlar döndürür, dolayısıyla önbelleğe alınmamalıdır.
Statik kaynaklarınız (CSS, JS, görsel dosyaları) sorgu dizeleri içerdiğinde, bazı sistemler bunları da dinamik içerik gibi değerlendirir ve önbellekleme yapmaktan kaçınır. Sonuç olarak, aslında hiç değişmeyen bir logo.png dosyası bile her sayfa yüklemesinde sunucudan tekrar indirilir. Bu durum hem kullanıcının bant genişliğini tüketir hem de sunucunuz üzerinde gereksiz yük oluşturur.
Google PageSpeed Insights gibi araçlar eskiden bu sorunu işaret ederdi ama günümüzde bu tavsiye kullanımdan kaldırıldı. Çünkü modern CDN’ler ve tarayıcılar query string’leri daha iyi yönetiyor. Ayrıca, HTTP/2 ve HTTP/3 gibi protokoller sayesinde birden fazla dosya indirme daha hızlı hale geldi, bu da query string sorunlarını azaltıyor. Bununla birlikte, eğer siteniz eski bir altyapıda çalışıyorsa veya hız testi gibi araçlarda hala “Remove query strings from static resources” uyarısı alıyorsanız, bu parametreleri kaldırmak faydalı olabilir.
Sorgu Dizelerinin Teknik Anatomisi
Bir web kaynağının URL’si birkaç farklı bileşenden oluşur ve her birinin önbellekleme açısından farklı anlamları vardır. Temel URL yapısı şu şekildedir:
https://orneksite.com/assets/style.css?ver=1.2.3&debug=trueBu URL’yi parçalara ayırdığımızda:
- Protocol (Protokol): https://
- Domain (Alan Adı): orneksite.com
- Path (Yol): /assets/style.css
- Query String (Sorgu Dizesi): ?ver=1.2.3&debug=true
Sorgu dizesi, soru işareti (?) ile başlar ve birden fazla parametre içerebilir. Parametreler “&” işareti ile ayrılır. Her parametre “anahtar=değer” formatındadır.
Sorgu dizelerinin önbellekleme üzerindeki etkisini anlamak için, HTTP önbellekleme başlıklarının nasıl çalıştığını bilmek gerekir. Bir tarayıcı veya proxy sunucusu bir kaynağı önbelleğe aldığında, o kaynağı URL’siyle birlikte saklar. “style.css” ile “style.css?ver=1.2.3” farklı URL’ler olarak kabul edilir ve ayrı ayrı önbelleklenir. Bu mekanizma aslında güncelleme durumlarında faydalıdır. Ancak sorun, bazı önbellekleme sistemlerinin sorgu dizesi içeren tüm URL’leri “önbelleğe alınmaması gereken dinamik içerik” olarak varsaymasıdır. Bu özellikle eski CDN’ler, paylaşımlı hostingler ve kurumsal proxy sunucularında yaygın bir durumdur.
Modern tarayıcılar ve CDN’ler genellikle sorgu dizeli statik kaynakları da önbelleğe alabilir, ancak web’deki tüm ara sistemlerin modern olduğunu garanti edemeyiz. İşte bu yüzden, sorgu dizelerini kaldırıp alternatif yöntemler kullanmak daha güvenli ve evrensel bir çözümdür.
WordPress’te Sorgu Dizelerini Statik Kaynaklardan Kaldırma
WordPress’in varsayılan yapısında CSS ve JavaScript dosyalarına otomatik olarak versiyon numaraları ekler. Bu durum, kullandığınız temanın ve eklentilerin de benzer şekilde davranmasına neden olur. Neyse ki, WordPress’in esnek yapısı sayesinde bu sorgu dizelerini kaldırmak oldukça kolaydır.
⚠️ Bu işlemleri denemeden önce mutlaka sitenizin bir yedeğini alın!
# Functions.php ile Manuel Çözüm
Bu yöntem, WordPress’in kendi API’sini kullanarak sorgu dizelerini kaldırır. Functions.php dosyasına aşağıdaki kodu ekleyin:
function remove_query_strings_from_static_resources($src) {
// Sorgu dizesi var mı kontrol et
if (strpos($src, '?ver=')) {
// Sorgu dizesini kaldır
$src = remove_query_arg('ver', $src);
}
return $src;
}
// CSS dosyaları için uygula
add_filter('style_loader_src', 'remove_query_strings_from_static_resources', 15, 1);
// JavaScript dosyaları için uygula
add_filter('script_loader_src', 'remove_query_strings_from_static_resources', 15, 1);Bu kod parçası şunları yapar: WordPress’in style_loader_src ve script_loader_src hook’larını kullanarak, CSS ve JavaScript dosyalarının URL’lerini işler. Her dosya URL’sinde “?ver=” parametresi varsa, bu parametreyi kaldırır ve temiz URL’yi döndürür. Kod, yalnızca versiyon parametresini kaldırır, diğer önemli parametreleri korur.
📌 Functions.php dosyasını düzenlemeden önce mutlaka yedek alın. Bir yazım hatası sitenizin çalışmamasına neden olabilir. Child theme kullanıyorsanız ki kullanmalısınız, kodu child theme’in functions.php dosyasına ekleyin.
# Eklenti ile Sorgu Dizelerini Kaldırma
- WP Rocket Eklentisi: WordPress ekosistemindeki en popüler önbellekleme eklentilerinden biridir ve sorgu dizelerini kaldırma özelliğini de içerir.
- WP Rocket eklentisini satın alın ve kurun
- WP Rocket ayarlar sayfasına gidin
- “File Optimization” sekmesine tıklayın
- “Remove query strings from static resources” seçeneğini işaretleyin
- Ayarları kaydedin.
- LiteSpeed Cache: Ücretsiz bir önbellek ve optimizasyon eklentisidir.
- Eklentiyi kurduktan sonra
Ayarlar > LiteSpeed Cache > Optimizasyon > "Remove Query Strings” seçeneğini ON yapın. Bu işlem, statik dosyaların ekstra sorgu oluşturmasını engeller ve Google reCAPTCHA gibi servislerle uyumlu çalışır.
- Eklentiyi kurduktan sonra
- Asset CleanUp Eklentisi: Sorgu dizelerini kaldırmanın yanı sıra, hangi sayfalarda hangi script’lerin yükleneceğini de kontrol etmenizi sağlayan ücretsiz bir eklentidir.
- Ücretsiz ve premium versiyonları mevcut
- Sayfa bazında script yönetimi
- Kullanımı oldukça kolay.
- Perfmatters Eklentisi: Perfmatters, WordPress için geliştirilmiş premium bir performans optimizasyon eklentisidir. Sorgu dizelerini kaldırma özelliğinin yanı sıra birçok optimizasyon seçeneği sunar.
- Perfmatters eklentisini satın alın ve yükleyin
- WordPress yönetim panelinde Perfmatters > Ayarlar’a gidin
- “Assets” sekmesini bulun
- “Remove Query Strings” seçeneğini aktif edin
- Değişiklikleri kaydedin.
- Speed Booster Pack: Tamamen ücretsiz olan bu eklenti, sorgu dizelerini kaldırma dahil birçok hız optimizasyonu sunar.
- Açık kaynak ve ücretsiz
- Türkçe dil desteği
- Basit ve anlaşılır arayüz.
- Manuel CDN Yöntemi: Cloudflare veya başka bir CDN kullanıyorsanız, Page Rules ile sorgu dizelerini yönetebilirsiniz.
Cloudflare’de statik kaynaklarınız için özel kurallar oluşturmak oldukça basittir:
- Cloudflare kontrol panelinize giriş yapın.
- İlgili domain’i seçin.
- “Rules” menüsünden “Page Rules”a tıklayın.
- “Create Page Rule” butonuna basın.
- URL pattern olarak şunu girin:
*orneksite.com/*.css*(CSS dosyaları için) - Şu ayarları ekleyin:
- Cache Level: Cache Everything
- Edge Cache TTL: 1 month
- Browser Cache TTL: 1 month
- Aynı işlemi JavaScript, görsel ve diğer statik kaynak tipleri için tekrarlayın.
- Cloudflare’in “Query String Sort” özelliği, sorgu dizelerini alfabetik olarak sıralar. Bu, aynı parametrelere sahip ama farklı sırayla yazılmış URL’lerin tek bir önbellek kaydı oluşturmasını sağlar:
- style.css?ver=1&color=blue
- style.css?color=blue&ver=1
- Bu iki URL normalde farklı önbellek kayıtları oluştururdu, ancak Query String Sort aktifse tek kayıt olarak işlenir. Bu özelliği aktif etmek için: Cloudflare > Caching > Configuration > Enable Query String Sort
# Dosya İsimlendirme ile Versiyon Yönetimi
Sorgu dizelerini kaldırdıktan sonra karşılaşabileceğiniz en büyük sorun, dosyaları güncellediğinizde kullanıcıların hala eski önbelleklenmiş versiyonları görmesidir. İşte bu noktada devreye dosya isimlendirme stratejileri girer. Bu yöntem, sorgu dizeleri olmadan da etkili önbellekleme kontrolü sağlar.
- Versiyon Numarası Yöntemi– En basit yöntem, dosya adına versiyon numarasını dahil etmektir:
- style-v1.css → style-v2.css
- script.1.0.js → script.1.1.js
- app-v1.2.3.css → app-v1.2.4.css
- Bu yöntemin avantajı, versiyon geçmişini takip etmenin kolay olmasıdır. Hangi dosyanın hangi versiyonda kullanıldığını net bir şekilde görebilirsiniz.
- Tarih Damgası Yöntemi– Dosya adına son güncelleme tarihini ekleme:
- style-20240115.css
- script-2024-01-15.js
- main-20240115143022.css
- Bu yöntem, özellikle sık güncelleme yapılan projelerde faydalıdır çünkü her güncelleme otomatik olarak yeni bir dosya adı oluşturur.
- Hash/Fingerprint Yöntemi (En İdeal)- Modern build araçları (Webpack, Vite, Gulp) dosya içeriğinden unique bir hash üretir:
- style.a7b3c2d.css
- script.9f3c1ae.js
- app.5d8f2b9a.css
- Bu yöntemin en büyük avantajı, dosya içeriği değişmedikçe hash’in aynı kalmasıdır. Yani gereksiz önbellek geçersizleştirmeleri olmaz.
WordPress’te bu yöntemi uygulamak için wp_enqueue_style ve wp_enqueue_script fonksiyonlarını kullanırken dosya adını özelleştirmeniz gerekir:
// Tema versiyonunu al
$theme_version = wp_get_theme()->get('Version');
// CSS'i versiyonlu isimle ekle
wp_enqueue_style(
'main-style',
get_template_directory_uri() . '/css/style-v' . $theme_version . '.css',
array(),
null // Versiyon parametresini null yap
);Bu yaklaşımda, versiyon bilgisi sorgu dizesi yerine dosya adının bir parçası olur. Böylece hem önbellekleme sorunlarından kaçınır hem de güncellemeleri etkili şekilde yönetirsiniz.
# .htaccess ile İleri Seviye Optimizasyonlar
Apache sunucu kullanıyorsanız, .htaccess dosyası üzerinden çok güçlü önbellekleme ve optimizasyon kuralları uygulayabilirsiniz. Bu yöntem, WordPress’in ötesine geçerek sunucu seviyesinde kontrol sağlar ve tüm statik kaynaklarınızı kapsar.
- .htaccess dosyanızın sonuna aşağıdaki kodu ekleyerek statik kaynaklar için güçlü önbellekleme kuralları oluşturabilirsiniz:
## TARAYICI ÖNBELLEKLEME BAŞLANGIÇ ##
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
## TARAYICI ÖNBELLEKLEME BİTİŞ ##| mod_expires Modülü | Cache-Control Başlıkları | GZIP Sıkıştırma |
|---|---|---|
| Apache’nin mod_expires modülü, dosya tipine göre önbellekleme süreleri belirlemenizi sağlar. Görseller 1 yıl, CSS/JS dosyaları 1 ay önbellekte kalır. | mod_headers modülü ile HTTP cache-control başlıklarını özelleştirebilir, daha ayrıntılı önbellekleme stratejileri uygulayabilirsiniz. | Dosya boyutlarını %70’e kadar azaltmak için GZIP sıkıştırması aktif edilmelidir. Bu, özellikle metin tabanlı dosyalar için kritiktir. |
- Gelişmiş Cache-Control Yapılandırması:
## CACHE CONTROL BAŞLANGIÇ ##
# Statik kaynaklara Cache-Control başlıkları ekle
Header set Cache-Control "public, max-age=31536000, immutable"
# HTML dosyaları için farklı kural
Header set Cache-Control "public, max-age=3600, must-revalidate"
## CACHE CONTROL BİTİŞ ##.htaccess optimizasyonları, sunucu seviyesinde çalıştığı için WordPress’teki herhangi bir eklenti veya temadan bağımsızdır. Bu, site performansınızı kalıcı olarak iyileştirir ve tema değişikliklerinden etkilenmez.
