Sunucu & Performans

HTTP/3 (QUIC) WordPress’i Gerçekten Hızlandırır mı?

HTTP/3 (QUIC) WordPress’i Gerçekten Hızlandırır mı?

Kısa cevap: HTTP/3, web trafiğini TCP yerine QUIC (UDP üzerinde) taşıyan yeni protokoldür. Kazancı ham hızda değil, bağlantı kurarken ve kötü ağlarda saklıdır: daha hızlı el sıkışma ve TCP’nin “head-of-line blocking” sorununun ortadan kalkması. Yani en çok mobil ve yüksek gecikmeli ağlardaki ziyaretçinize fayda sağlar; iyi bir kablolu bağlantıda fark çoğu zaman küçüktür. nginx 1.25+ ile açılır, ama “açınca her şey uçar” beklemeyin.

HTTP/3 son yıllarda yavaşça standart oldu ama az anlaşılıyor: “açınca site uçar mı, yoksa pazarlama mı?” İkisi de değil. Bu yazıda QUIC’in ne olduğunu, nginx’te nasıl açıldığını ve WordPress siteniz için gerçekten ne ifade ettiğini abartısız anlatıyoruz. Web sunucusu seçimini ve performans katmanlarını ayrı yazılarda ele aldık; bu protokol katmanını tamamlıyor.

QUIC nedir, neyi çözer?

HTTP/1.1 ve HTTP/2 verisini TCP üzerinde taşır. TCP güvenilirdir ama bir paket kaybolduğunda arkasındaki tüm paketler bekler — buna head-of-line blocking denir ve kötü ağlarda yavaşlık üretir. HTTP/3 ise veriyi QUIC ile, yani UDP üzerinde taşır ve bu sorunu protokol seviyesinde çözer.

Özellik HTTP/2 HTTP/3 (QUIC)
Taşıma TCP UDP (QUIC)
Head-of-line blocking Var (TCP seviyesinde) Yok
El sıkışma (handshake) TCP + TLS ayrı Birleşik, daha hızlı (0-RTT mümkün)
Şifreleme TLS (opsiyonel) TLS 1.3 zorunlu
Ağ değişiminde (Wi-Fi↔mobil) Bağlantı kopar Bağlantı taşınır (connection migration)

nginx’te HTTP/3 nasıl açılır?

nginx, 1.25.0 sürümüyle HTTP/3 desteğini getirdi. Açmak için QUIC dinleyicisi, HTTP/2 fallback’i ve tarayıcıya HTTP/3’ün mevcut olduğunu söyleyen Alt-Svc başlığı gerekir:

server { … } bloğu
server {
    # HTTP/2 (TCP) — fallback
    listen 443 ssl;
    # HTTP/3 (QUIC, UDP) — aynı port
    listen 443 quic reuseport;

    ssl_protocols TLSv1.2 TLSv1.3;   # QUIC için TLS 1.3 şart

    # Tarayıcıya "HTTP/3 burada" de:
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}
Unutulan adım: UDP 443’ü açın

QUIC, TCP değil UDP üzerinden çalışır. Güvenlik duvarınızda yalnız TCP 443 açıksa HTTP/3 sessizce çalışmaz — site HTTP/2’ye düşer ve “neden HTTP/3 görünmüyor?” dersiniz. UDP 443’ü de açın. Ayrıca reuseport, çoklu worker’la doğru çalışması için gereklidir.

Doğrulama: tarayıcı geliştirici araçlarında protokol h3 görünmeli, ya da:

bash
# HTTP/3 destekli curl ile:
curl --http3 -I https://siteniz.com/
# İlk istek HTTP/2 olabilir; Alt-Svc'i gören tarayıcı sonraki isteklerde h3'e geçer.

WordPress’i gerçekten hızlandırır mı?

Dürüst cevap: duruma göre. HTTP/3’ün kazancı, sunucunun ham hızında değil, ağ koşullarındadır:

  • En çok fayda: mobil, yüksek gecikmeli veya paket kaybı olan ağlardaki ziyaretçiler — handshake gecikmesi ve head-of-line blocking ortadan kalkar.
  • Az fayda: düşük gecikmeli, sağlam kablolu bağlantıda fark çoğu zaman ölçülemeyecek kadar küçüktür.
  • Etkilemez: sunucunuzun TTFB’sini HTTP/3 düşürmez — o, önbellek/PHP/veritabanı işidir. HTTP/3 taşıma katmanını iyileştirir, uygulama katmanını değil.

Yani HTTP/3, mobil ağırlıklı ya da küresel kitlesi olan siteler için anlamlı bir cilalamadır; ama yavaş bir sunucuyu hızlı yapmaz. Önce TTFB ve önbellek, sonra HTTP/3.

En kolay yol: Cloudflare

nginx’i yeniden yapılandırmak istemiyorsanız, siteyi Cloudflare arkasına almak HTTP/3’ü kenar (edge) tarafında otomatik sağlar — ziyaretçi ile Cloudflare arası HTTP/3 olur, origin sunucunuza dokunmadan. Çoğu site için en düşük çabayla en geniş HTTP/3 kapsamı budur.

DKS pratikte ne yapıyor?

HTTP/3’ü “olursa iyi olur” katmanı olarak ele alıyoruz: önce sunucunun TTFB’sini ve önbelleğini doğru kuruyor, sonra mobil/küresel kitlesi olan sitelerde HTTP/3’ü origin’de (nginx 1.25+, UDP 443 açık, Alt-Svc) ya da Cloudflare kenarında etkinleştiriyoruz. Kararı yine ölçü belirliyor: ziyaretçi profili mobil/uzak mı, yoksa yerel kablolu mu? Performans optimizasyonu tarafında bu protokol katmanını da kuruyoruz — ama abartmadan, gerçek faydası olan yerde.

Sıkça sorulan sorular

HTTP/3 ile HTTP/2 arasındaki fark nedir?

HTTP/2 veriyi TCP üzerinde taşır ve paket kaybında head-of-line blocking yaşar; HTTP/3 ise QUIC ile UDP üzerinde taşır, bu sorunu çözer, daha hızlı el sıkışma sağlar ve ağ değişiminde bağlantıyı koruyabilir. HTTP/3 ayrıca TLS 1.3 kullanmayı zorunlu kılar.

HTTP/3 sitemi ne kadar hızlandırır?

Ağ koşullarına bağlıdır. En çok mobil, yüksek gecikmeli veya paket kaybı olan ağlardaki ziyaretçilerde fayda sağlar; iyi bir kablolu bağlantıda fark küçük olabilir. Sunucunuzun TTFB’sini düşürmez — o önbellek ve veritabanı işidir; HTTP/3 yalnız taşıma katmanını iyileştirir.

nginx’te HTTP/3 için ne gerekir?

nginx 1.25.0 veya üstü, server bloğunda listen 443 quic reuseport, TLS 1.3 ve Alt-Svc başlığı gerekir. Kritik nokta: QUIC UDP üzerinden çalıştığı için güvenlik duvarında UDP 443 portunu da açmanız şarttır, yoksa site sessizce HTTP/2’ye düşer.

HTTP/3 için Cloudflare şart mı?

Hayır, ama en kolay yoldur. Siteyi Cloudflare arkasına alırsanız ziyaretçi ile Cloudflare arası HTTP/3 otomatik olur, origin sunucuya dokunmanız gerekmez. Alternatif olarak nginx 1.25+ ile HTTP/3’ü doğrudan kendi sunucunuzda da açabilirsiniz.

HTTP/3 güvenli mi?

Evet, hatta şifreleme zorunludur: QUIC, TLS 1.3’ü mecbur kılar, yani tüm HTTP/3 trafiği şifrelidir. Bu, HTTP/2’de opsiyonel olan şifrelemeyi protokol seviyesinde standart hale getirir.

Sunucunuz modern protokollere hazır mı?

HTTP/3, doğru kurulmuş bir sunucunun üstüne anlamlı bir katmandır. Bizimle iletişime geçin; önce TTFB ve önbelleğinizi ölçüp, ardından gerçekten fayda sağlayacaksa HTTP/3’ü kuralım.

Digital Kernel Software

Digital Kernel Software

WordPress tema geliştirme, hosting ve sunucu performansı üzerine yazıyoruz. İstanbul / Türkiye.

Projeniz mi var?

Okuduğunuzu
projenize uygulayalım

WordPress, hosting ve performans tarafında yazdıklarımızı sizin işinizde hayata geçirelim. Net konuşuruz — pazarlama dili değil, uygulanabilir çözüm.