WordPress’te HTTP/2 ve HTTP/3 desteği nasıl açılır?

WordPress’te sayfa hızını artırmanın en somut yollarından biri, tarayıcı ile sunucu arasındaki bağlantı protokolünü doğru kullanmaktır. HTTP/2, tek bağlantı üzerinden çoklu istekleri daha verimli taşır; HTTP/3 ise QUIC (UDP) üzerinden bağlantı kurulum gecikmesini azaltmayı hedefler. Bu yazıda, HTTP/2/HTTP/3’ün WordPress’te “açılır açılmaz” çalışmamasının ana nedenlerini (TLS, reverse proxy, CDN, WAF) netleştirip, her adımı test ile doğrulayacağınız bir kontrol akışı sunacağız.

Aşağıdaki rehber; Apache/Nginx/Cloudflare gibi yaygın bileşenler ve WordPress tarafındaki pratik ayarlarla ilerler. Amaç, “sadece ayar yaptım” değil; gerçekten protokolün devrede olduğunu kanıtlayabilmenizdir.

HTTP/2 ve HTTP/3 WordPress’te nerede devreye girer?

HTTP/2 ve HTTP/3 çoğunlukla WordPress’in PHP katmanında açılmaz. Protokol, tarayıcı → kenar (edge) / CDN → web sunucusu (reverse proxy) → origin akışında gerçekleşir.

Tipik akış (en sık senaryolar)

Tarayıcı domain’e istek atar.
Eğer CDN veya reverse proxy varsa (ör. Cloudflare), protokol burada sonlanır.
Origin (WordPress’in barındığı Nginx/Apache) çoğu zaman HTTP/1.1 veya HTTP/2 ile konuşabilir; asıl önemli olan tarayıcının hangi protokolle bağlandığıdır.

Bu yüzden “HTTP/3’ü WordPress’ten açtım” ifadesi çoğu durumda hatalıdır. Doğrusu: “Sitenin uç noktası HTTP/3 konuşuyor mu?” sorusudur.

Ön koşullar: HTTP/2 ve HTTP/3 için TLS ve sunucu hazırlığı

Protokol etkinleştirmeden önce şu kontrolü net yapın.

1) HTTPS zorunludur

HTTP/2 için sitenin HTTPS üzerinden çalışması gerekir.
HTTP/3 de HTTPS (TLS 1.3) üzerine kurulur.

Kontrol: Tarayıcı adres çubuğunda kilit açık mı? Ayrıca sitenizde TLS sertifikası zinciri sorunsuz mu?

2) Sunucu yazılımı ve ters proxy

Aşağıdakiler pratikte belirleyicidir: - Nginx sürümü ve HTTP/3 modül/alternatif paketleri - Apache kullanılıyorsa QUIC/HTTP3 desteği genelde daha sınırlıdır; çoğunlukla proxy/CDN üzerinden çözülür. - Cloudflare, Fastly, Akamai gibi CDN’lerde HTTP/3 genellikle kenarda aktiftir.

3) CDN/WAF katmanı protokolü etkiler

WAF veya DDoS servisleri HTTP/3 akışını engelleyebilir; doğru modun açık olması gerekir.

WordPress’te HTTP/2 açma: en hızlı yol haritası

HTTP/2 çoğu modern web sunucusunda varsayılan olarak çalışır; fakat doğrulama şarttır.

Adım adım doğrulama (önce test)

Sitenizi şu araçlarla kontrol edin: - Google Chrome DevTools → Network sekmesi → istek detaylarında protokol bilgisi - cURL ile test:
- curl -I --http2 https://ornek.com
Sonuçta response header tarafında / bağlantı bilgisinde HTTP/2 kullanımı görünmeli.

Nginx (origin) tarafında tipik ayar mantığı

Eğer origin tarafında Nginx yönetiyorsanız (VDS/VPS üzerinde), HTTP/2 çoğu zaman listen direktifiyle açılır.

Örnek mantık (dosya adı değişebilir): - listen 443 ssl http2;

Not: Bu, CDN yoksa tarayıcının origin’e doğrudan bağlandığı durumda önem kazanır.

Apache origin tarafında mantık

Apache’de HTTP/2 genellikle şu prensiple açılır: - SSL modülleri + HTTP/2 desteği etkin olmalı.

Ancak pratikte en az sürpriz yöntem CDN üzerinden HTTP/2/3’ü aktif etmek ve origin’i stabil tutmaktır.

WordPress’te HTTP/3 (QUIC) açma: CDN ile gerçekçi yaklaşım

HTTP/3’ün WordPress’te “açılır” kısmı çoğunlukla iki yoldan biridir: - CDN kenarında HTTP/3’ü aktif etmek (en yaygın) - Origin sunucusunda doğrudan HTTP/3’ü destekleyen altyapı kurmak (VDS üzerinde kontrol daha fazla)

CDN kullanıyorsanız (en sık kazanç)

Cloudflare gibi bir CDN üzerinden ilerliyorsanız, yapılacaklar genelde şöyledir: 1. CDN panelinde HTTP/3 seçeneğini etkinleştirin. 2. HTTPS aktif ve TLS durumunu kontrol edin. 3. İstekleri test edin.

HTTP/3 test için pratik komut: - curl -I --http3 https://ornek.com

Ayrıca Chrome DevTools’ta istek protokolünün h3 görünmesi beklenir.

CDN yoksa ya da origin’de istiyorsanız

Bu durumda Nginx/Apache sürüm ve QUIC yapılandırması kritik hale gelir. Ayrıca UDP trafiğinin engellenmemesi ve firewall kuralları önemlidir.

VDS üzerinde çalışırken kontrol listesi: - TLS 1.3 etkin mi? - Web sunucusu HTTP/3’ü destekliyor mu? - Firewall/SG (security group) UDP 443 geçişine izin veriyor mu? - Reverse proxy (varsa) HTTP/3’ü iletebiliyor mu?

Test rehberi: “Açtım” değil “çalışıyor” kanıtı

Protokol etkinliğini doğrulamak için tek bir test türüne güvenmeyin. Aşağıdaki yöntem kombinasyon en sağlıklısıdır.

1) Tarayıcı (Chrome DevTools)

Network sekmesinde sayfayı yenileyin (Hard reload).
İlk HTML isteğini açın.
Protokol bilgisinde HTTP/2 veya HTTP/3/QUIC ayrımını görün.

2) cURL

HTTP/2: curl -I --http2 https://ornek.com
HTTP/3: curl -I --http3 https://ornek.com

HTTP/3 için bazı ortamlarda (kurulumun/derlemenin türüne bağlı olarak) komut başarısız olabilir. Bu durumda tekrar tarayıcı doğrulaması yapın.

3) Mantık kontrolü: CDN varsa origin yerine kenarı test edin

CDN kullanıyorsanız: - Test ettiğiniz URL, CDN üzerinden mi gidiyor? - DNS kayıtları CDN’e mi yönlendiriyor?

Aksi halde HTTP/3’ü origin’de açmış olsanız bile tarayıcı CDN üzerinden konuştuğu için sizin origin ayarlarınız test sonucunu etkilemez.

Sık senaryolar: Hangi ayar sizde işe yarar?

Aşağıdaki tablo, uygulama kararınızı hızlandırır.

Senaryo	HTTP/2/HTTP/3’ü nerede açmanız gerekir?	En doğru test	WordPress tarafı gerekir mi?
CDN kullanıyorsunuz (Cloudflare vb.)	CDN panelinde HTTP/2/HTTP/3	Chrome DevTools protokol/h3 kontrolü	Genelde hayır
VDS üzerinde Nginx yönetiyorsunuz (CDN yok)	Nginx/Reverse proxy konfigürasyonu	cURL + tarayıcı doğrulama	Sınırlı (cache eklentileri destek gerekebilir)
Paylaşımlı hosting	Sağlayıcı web sunucusu veya CDN	Tarayıcı protokol testi	Genelde sadece eklenti gerekmez
Reverse proxy + WAF var	Proxy/CDN + WAF uyumu	WAF sonrası protokol testi	Genelde hayır

WordPress eklentileriyle ilgili net çerçeve

HTTP/2/HTTP/3, WordPress eklentileriyle çoğu zaman “açılmaz”. Eklentiler şu alanlarda yardımcı olabilir: - Cache (sayfa önbelleği) - CDN kullanıyorsanız doğru origin başlıkları (cache-control) üretmek - Görsel optimizasyon (protokolün kendisi değil, içerik boyutu)

Bu nedenle “HTTP/3 eklentisi” arayışı yerine önce sunucu/CDN doğrulaması yapılmalıdır.

Performans etkisi: HTTP/3 hangi durumda fark yaratır?

HTTP/3’ün katkısı her projede aynı görünmez. En somut farkların görüldüğü durumlar: - Mobil ağlar ve değişken bağlantı koşulları - Paket kaybı yaşayan ağlar - Çoklu istekli sayfalarda (CSS/JS ve farklı kaynaklar)

Ama HTTP/3’ün tek başına mucize olmadığı noktalar: - Görseller ve script boyutu büyükse önce optimizasyon gerekir. - Server TTFB (ilk yanıt süresi) yüksekse protokol tek başına her şeyi çözmez.

Uygulama planı: 30 dakikalık net kontrol akışı

Aşağıdaki sırayla ilerlerseniz gereksiz ayar döngülerini azaltırsınız.

HTTPS doğrulaması: Siteniz tam HTTPS mi?
DNS/akış haritası: CDN var mı? Varsa DNS Cloud ağına mı yönlendiriyor?
HTTP/2 testi: curl -I --http2 ... + Chrome DevTools.
HTTP/3 testi: curl -I --http3 ... + Chrome DevTools (h3 görülmeli).
Gerekliyse CDN panelinde HTTP/3’ü aktif edin.
CDN yoksa origin’de Nginx/Proxy tarafında HTTP/3 desteğini kontrol edin (UDP/443 ve TLS 1.3).

Sonuç: Aksiyon önerisi

Bugün yapmanız gereken en net iş, HTTP/2 ve HTTP/3’ü ayar menüsünden ziyade test kanıtıyla doğrulamak. CDN kullanıyorsanız HTTP/3’ü kenarda aktifleştirin ve Chrome DevTools’tan protokolü teyit edin; CDN yoksa VDS/VPS tarafında Nginx/QUIC altyapısı ve UDP/443 geçişini kontrol edin. Bu adımları tamamladığınızda, WordPress tarafında gereksiz eklenti aramak yerine doğrudan hız ve güvenilirlik optimizasyonuna geçebilirsiniz.