HTTP/2 ve HTTP/3: SEO, Core Web Vitals ve Hosting Seçimi

HTTP/2 ve HTTP/3 Desteği SEO Açısından Neden Önemli?

SEO değerlendirmesinde içerik, backlink ve teknik hata temizliğinin (404, yönlendirmeler vb.) yanında kullanıcı deneyimi de önemlidir. Google’ın Page Experience açıklamalarında Core Web Vitals metriklerinin sıralama sistemlerinde kullanıldığı belirtilir; bu, hosting veya protokol seçiminin tek başına sıralama avantajı sağladığı anlamına gelmez. Altyapıyı değerlendirirken yalnızca “sunucu yanıt veriyor mu?” değil, ne kadar hızlı ve kararlı yanıt veriyor? sorusunu da sormak gerekir.

HTTP/2 ve HTTP/3 (QUIC) tam da bu noktada devreye giriyor. Aynı sunucu donanımında, aynı kod tabanı ile, sadece protokolü güncelleyerek bile ölçülebilir seviyede TTFB düşüşü, LCP iyileşmesi ve daha akıcı bir kullanıcı deneyimi elde etmek mümkün. Kazanç; ağ koşullarına, bağlantının yeniden kullanımına ve uygulamanın darboğazlarına bağlıdır; aynı içerik ve benzer trafik koşullarında ölçülmelidir.

Bu yazıda, HTTP/2 ve HTTP/3’ün tam olarak neyi değiştirdiğini, SEO ve Core Web Vitals metriklerine etkisini ve hosting seçerken nelere bakmanız gerektiğini sade ama teknik olarak tutarlı bir dille toparlayacağız. Yazının sonunda, elinizde HTTP protokol desteğini de içeren net bir hosting değerlendirme check-list’i olacak.

HTTP/1.1, HTTP/2 ve HTTP/3 Arasındaki Temel Farklar

SEO ve Core Web Vitals etkisini anlamanın ilk adımı, bu üç protokol arasındaki yapısal farkları netleştirmek.

HTTP/1.1: Tek Şeritli Yol

HTTP/1.1’de tarayıcı genellikle kalıcı TCP bağlantılarını yeniden kullanır; paralellik için birden fazla bağlantı açar ve her bağlantıda istekleri çoğunlukla sırayla işler. Bu yapı:

• Head-of-line blocking (yavaş bir yanıt aynı bağlantıdaki sonraki yanıtları bekletebilir),
• Çok sayıda TCP bağlantısı açma maliyeti,
• Header’ların sıkıştırılmaması nedeniyle gereksiz veri trafiği

gibi nedenlerle özellikle çok dosyalı (CSS, JS, görsel) sayfalarda ciddi gecikmelere yol açabilir.

HTTP/2: Aynı Hat Üzerinden Birden Fazla Şerit

HTTP/2, temelde hâlâ TCP üzerinde çalışır ama şunları getirir:

• Multiplexing: Aynı TCP bağlantısı üzerinde aynı anda birden fazla istek/yanıt akabilir.
• HPACK header sıkıştırma: Tekrarlayan HTTP header’ları çok daha küçük boyutta iletilir.
• Sunucu itme (server push): Protokol, istemci istemeden kaynak gönderilmesini tanımlar; ancak istemci desteği olmadan kullanılamaz ve genel bir tarayıcı performans avantajı olarak varsayılmamalıdır.

Bu sayede tarayıcı, tek bir ana bağlantı üzerinden aynı anda çok sayıda isteği verimli biçimde yönetebilir. HTTP/1.1 için kullanılan domain sharding ek bağlantı maliyeti yaratabileceğinden yeniden değerlendirilmelidir. Sprite ve dosya birleştirme kararını ise istek sayısı, önbellek ve aktarım boyutu dengesine göre verin.

HTTP/3 (QUIC): TCP Bariyerini Aşmak

HTTP/3, bir önceki nesil HTTP protokollerinden farklı olarak TCP yerine UDP üzerinde çalışan QUIC protokolünü kullanır. Öne çıkan farklar:

• Transport seviyesi multiplexing: Bir akışın kayıp verisinin yeniden iletilmesi, ilgisiz akışların teslimini bekletmez; bağlantının ortak tıkanıklık kontrolü devam eder.
• 0-RTT ve 1-RTT handshake: TLS el sıkışması QUIC bağlantı kurulumuyla bütünleşiktir. Yeni bağlantı genellikle 1-RTT gerektirir; 0-RTT yalnızca uygun önceki oturum bilgileriyle ve erken verinin kabul edildiği durumlarda mümkündür. Erken veri yeniden oynatılabileceği için yalnızca buna uygun isteklerde kullanılmalı; rastgele durum değiştiren işlemlere uygulanmamalıdır.
• Paket kaybına daha iyi tolerans: Tek bir akıştaki kayıp, diğer akışların verilerinin teslimini doğrudan bloke etmez; ancak ortak tıkanıklık kontrolü nedeniyle diğer akışların hızı da etkilenebilir.

Sonuç olarak HTTP/3, özellikle mobil kullanıcılar, Wi‑Fi üzerinden bağlananlar ve coğrafi olarak uzak ziyaretçilerde ilk byte’a ve ilk boyalı piksellere gidişi hızlandırabilir. Kazanç ağ ve bağlantı koşullarına bağlıdır; LCP’ye katkısı ölçülmelidir.

HTTP/2 ve HTTP/3’ün SEO ile Dolaylı İlişkisi

Google, “HTTP/3 kullanırsan +x sıra veririm” gibi doğrudan bir kriter açıklamıyor. Core Web Vitals sıralama sistemlerinde kullanılır; ancak protokol değişikliğiyle sağlanan performans iyileşmesi daha yüksek sıralamayı garanti etmez.

1. Tarama Bütçesi ve Crawl Verimliliği

Googlebot’un tarama hızı sınırsız değildir. Tarama bütçesi, özellikle çok sayıda URL içeren sitelerde değerlendirilmelidir. Yavaş yanıtlar tarama kapasitesini sınırlayabilir; ancak daha hızlı yanıt vermek tek başına daha fazla URL’nin taranacağını göstermez. Google’ın tarayıcı belgeleri HTTP/1.1 ve HTTP/2 desteğini açıklar; protokol seçimi gözlenen tarama performansına göre değişebilir. HTTP/2, site ve Googlebot için işlem kaynaklarından tasarruf sağlayabilir; Google Search’te sıralama artışı sağlamaz. Bu belge Googlebot için HTTP/3 desteği veya daha fazla URL taranacağı garantisi vermez. Tarama açısından protokol avantajlarından ancak botun gerçekten kullandığı bağlantıda yararlanılabilir:

• Çoğullama, desteklenip kullanıldığında bağlantı maliyetini azaltabilir; bu tek başına daha fazla URL taranacağı anlamına gelmez.
• TTFB azalabilir, ancak uygulama ve veritabanı beklemeleri protokol değişikliğiyle ortadan kalkmaz.
• 5xx ve zaman aşımı sorunları için uygulama hataları ve kapasite sınırları ayrıca incelenmelidir; yeni protokol bunları kendiliğinden çözmez.

Özellikle çok sayıda kategori/ürün sayfası olan e‑ticaret sitelerinde, tarama verimliliğini sunucu günlükleri ve tarama raporlarıyla değerlendirin; bunu sıralama istikrarıyla veya tarayıcı–CDN HTTP/3 ölçümüyle eşitlemeyin.

2. Page Experience ve Core Web Vitals Sinyalleri

Güncel Core Web Vitals metrikleri LCP, INP ve CLS’dir. Altyapı performansı özellikle yüklemeyi etkiler; INP ve CLS üzerindeki etki daha dolaylıdır. Bu konuda detaylı bir sunucu tarafı perspektifini, hazırladığımız Core Web Vitals ve hosting altyapısı rehberinde bulabilirsiniz.

HTTP/2 ve HTTP/3’ün katkı sağlayabileceği noktalar ve sınırları:

• TTFB (Time to First Byte): Daha verimli bağlantı yönetimiyle ilk bayt süresi düşebilir.
• LCP (Largest Contentful Paint): Kritik kaynakların daha erken ulaşması LCP zamanını kısaltabilir; kaynak keşfi ve render gecikmeleri ayrıca önemlidir.
• INP: Protokol, ana thread’in JS iş yükünü veya render bloklayan kaynak sayısını azaltmaz; etkileşim performansı ayrıca optimize edilmelidir.

3. Mobil SEO ve Zayıf Ağ Koşulları

Mobil ve dalgalı ağlar, HTTP/3’ün olası avantajlarını değerlendirmek için uygun senaryolardır. Kullanıcı deneyimi açısından şu noktalar ölçülebilir:

• Wi‑Fi > LTE gibi ağ geçişlerinde, desteklenen QUIC bağlantı göçü mevcut bağlantının sürmesini sağlayabilir; kesintisiz yükleme garanti değildir.
• Bağlantı tamamen sona ermişse yeni bağlantı gerekir; uygun oturum bilgileri yeniden kurulumu hızlandırabilir.
• Uzak kullanıcılarda el sıkışma turlarının azalması yarar sağlayabilir; RTT (gidiş-dönüş süresi) ortadan kalkmaz ve ilk boyama kazancı garanti değildir.

Bu olası kazanımları gerçek mobil kullanıcı ölçümleriyle değerlendirin; kullanıcı performansını Google’ın mobil botunun tarama davranışıyla eşitlemeyin.

4. Kullanıcı Davranışları: Hemen Çıkma, Scroll Derinliği, Dönüşüm

SEO sadece sıralama değil; sonuç sayfasına çıkan sayfanın tıklama sonrası performansı da önemli. HTTP/2 ve HTTP/3 geçişinden sonra şu olası etkiler ölçülebilir:

• İçeriğin daha erken kullanılabilir olması, kullanıcının sayfanın “donduğu” hissini azaltabilir; JS kaynaklı takılmalar ayrıca çözülmelidir.
• Scroll derinliği ve oturum süresi değişebilir; yönü içerik ve kullanıcı amacına da bağlıdır.
• Ödeme/adres formlarında ağ beklemelerinin azalması dönüşüme katkı sağlayabilir; uygulama ve form kullanılabilirliği de belirleyicidir.

Google Analytics veya başka analitik araçlarla, HTTP/2/3 geçişi öncesi/sonrası karşılaştırmaları yapabilirsiniz; trafik kaynağı, cihaz dağılımı ve eşzamanlı site değişikliklerini hesaba katmadan farkı yalnızca protokole bağlamayın.

Core Web Vitals Üzerindeki Etkileri Parça Parça İnceleyelim

HTTP/2 ve HTTP/3’ün Core Web Vitals metriklerine etkisini, üç güncel metrik üzerinden konuşalım: LCP, INP ve CLS. TTFB, Core Web Vitals metriği değildir; LCP’yi açıklamaya yardımcı bir yükleme ölçümüdür.

TTFB ve LCP: HTTP/2/3’ün En Doğrudan Dokunduğu Yer

TTFB, isteğin başlangıcından yanıtın ilk baytının alınmasına kadar geçen süreyi ölçer; yalnızca sunucu işleme süresi değildir. TTFB bir Core Web Vitals metriği değildir. LCP, görünüm alanındaki ölçüme uygun en büyük görsel, video karesi veya metin bloğunun çizilme zamanıdır; sayfanın anlam bakımından ana içeriğini seçmez. HTTP/2 ve HTTP/3 bu iki metriğin ağ kaynaklı bileşenlerine katkı sağlayabilir:

• Aynı bağlantı üzerinden birden fazla isteği çoklayarak kritik CSS ve JS dosyalarının bağlantı kaynaklı beklemesini azaltabilir; akış sınırları, önceliklendirme ve bant genişliği sonucu etkiler.
• Header sıkıştırma, başlıkların aktarım boyutunu azaltabilir; görsel, CSS veya JS gövdelerini küçültmez.
• QUIC sayesinde, el sıkışma turlarının azalması ve akışlar arası beklemenin sınırlanması LCP’ye katkı sağlayabilir; ilk ziyarette protokolün keşfi ve bağlantı kurulumu da sonucu etkiler.

Eğer sitenizde büyük görseller ve ağır JS’ler varsa, sadece HTTP/2/3’e geçmek yetmeyecek; görsel optimizasyonu ve önbellekleme tarafını da çalışmak gerekir. Bu konuda WebP/AVIF dönüşümü ve CDN ile görsel optimizasyonu anlattığımız rehberi mutlaka gözden geçirmenizi öneririz.

INP: Protokolün Katkısı Neden Dolaylı?

INP (Interaction to Next Paint), ziyaret boyunca etkileşimlerin sonraki boyamaya kadar olan gecikmelerini değerlendirir. Önceki metrik FID (First Input Delay) ise yalnızca ilk etkileşimde olay işleyicisinin çalışmaya başlamasına kadar olan gecikmeyi ölçerdi. INP açısından aktarım hızının katkısı dolaylıdır:

• Kaynaklar daha erken ulaşabilir; ancak JS’nin parse ve çalıştırma maliyeti azalmaz.
• CSS/JS aktarımında çoğullama beklemeyi azaltabilir; kaynakların render bloklama niteliğini değiştirmez.
• HTTP/3 ağdaki akışlar arası beklemeyi sınırlayabilir; ana thread, olay işleyicileri ve boyama maliyeti ayrıca optimize edilmelidir.

Yani HTTP/2 ve HTTP/3, kötü yazılmış dev JS paketlerini sihirli şekilde hızlandırmaz; ama iyi optimize edilmiş bir frontend için kaynak aktarım süresini azaltabilecek bir altyapı sunar.

CLS: Protokol Değişikliği Görsel Kararlılığı Garanti Etmez

CLS (Cumulative Layout Shift), sayfanın kullanımı boyunca oluşan beklenmedik yerleşim kaymalarını değerlendirir; yalnızca ilk yüklemeyle sınırlı değildir. HTTP sürümü bu kaymaları doğrudan önlemez; kaynakların geliş zamanlaması dolaylı olarak etkili olabilir:

• CSS ve font dosyalarının daha erken gelmesi, görünmez metin (FOIT) veya geçici font gösterimi (FOUT) süresini kısaltabilir. Ancak font değişimindeki yerleşim kayması, font metriklerine ve yükleme stratejisine de bağlıdır.
• Görseller için HTML’de boyut veya CSS’te en-boy oranı tanımlayarak yüklenmeden önce yer ayırmak, kaymaları önlemeye yardımcı olur; yalnızca CSS’in daha hızlı gelmesine güvenilmemelidir.

Özellikle third‑party script’ler (reklam, canlı sohbet, izleme kodları) kullanıyorsanız, bu kaynakların farklı yükleme zamanlarında sayfaya eklediği öğeleri ve oluşturduğu yerleşim kaymalarını test edin. HTTP/2/3 kullanımı tek başına CLS’yi stabil tutmaz.

Hosting Seçerken HTTP/2 ve HTTP/3 Açısından Nelere Bakmalısınız?

Protokollerin teorik faydası kadar, pratikte gerçekten aktif ve doğru konfigüre edilmiş olmaları da şart. Hosting seçerken kontrol etmeniz gereken kritik başlıkları adım adım toparlayalım.

1. Web Sunucusu ve TLS Altyapısı

HTTP/2 ve HTTP/3 desteği sadece “evet/hayır” sorusu değildir; hangi web sunucusuyla, hangi TLS sürümü ve şifre takımlarıyla çalıştığı da önemlidir.

• HTTP/2 desteği: Nginx, Apache (mod_http2) veya LiteSpeed kullanılan bir planda ilgili sürüm, modül ve yapılandırmayı kontrol edin. paylaşımlı hosting seçerken desteğin etkin olup olmadığını ve ayarların sağlayıcı tarafından mı, panel üzerinden mi yönetildiğini doğrulayın.
• HTTP/3/QUIC desteği: Nginx, Caddy, LiteSpeed veya CDN seçimini yalnızca ürün adına göre yapmayın; kullanılan sürüm/derlemenin HTTP/3 desteğini ve ilgili uçta etkinliğini doğrulayın. TLS 1.3 ve ALPN, sertifikanın değil, bağlantıyı sonlandıran sunucu veya CDN’nin TLS yapılandırmasının parçasıdır. HTTP/3 için TLS 1.3 gerekir; HTTP/2’nin HTTPS bağlantısında TLS 1.2 veya sonrası kullanılır. TLS’i ve HTTP/3’ü etkinleştirmek tek başına ağ üzerinden kullanılabilirliği kanıtlamaz.
• SSL/TLS optimizasyonu: Zayıf şifre takımlarının kapatılması ve HSTS, HTTPS güvenliği açısından değerlendirilmelidir; bunlar tek başına hız garantisi değildir. OCSP stapling ise sertifika otoritesine ve sertifikaya bağlıdır; Let’s Encrypt’in 6 Ağustos 2025’te OCSP hizmetini kapatması nedeniyle güncel Let’s Encrypt sertifikalarında beklenmemelidir. Bu başlıkları modern HTTPS için SSL/TLS yol haritası yazımızda detaylandırdık.

Paylaşımlı hosting, VPS ve dedicated sunucu seçeneklerini karşılaştırırken HTTP/2’nin etkinliğini, HTTP/3 desteğini ve yapılandırma sorumluluğunu seçtiğiniz plan için doğrulayın. Nginx ve Cloudflare kombinasyonu için adım adım kurulum rehberini Nginx ve Cloudflare’da HTTP/2 ve HTTP/3’ü etkinleştirme yazımızda anlattık.

2. Network ve Veri Merkezi Mimarisi

Protokol ne kadar modern olursa olsun, arka plandaki ağ kalitesi zayıfsa beklediğiniz kazanımları göremeyebilirsiniz.

• Network omurgası ve peering: Operatör bağlantılarını ve rotaları hedef kullanıcı bölgelerinden gecikme ve paket kaybı ölçümleriyle değerlendirin; doğrudan peering tek başına HTTP/3 performans kazancı göstermez.
• Sunucu lokasyonu: Hedef kitleniz ağırlıklı olarak Türkiye’deyse, Türkiye veya yakın bölge veri merkezleri ağ gecikmesini ve dolayısıyla TTFB’yi azaltabilir; gerçek sonucu yönlendirme, önbellek ve uygulama yanıt süresi de belirler. Bu konuyu sunucu lokasyonunun SEO’ya etkisi yazımızda örnek gecikme değerleriyle tartıştık.
• IPv6 desteği: IPv6 üzerinden hizmet verecekseniz DNS, yönlendirme ve güvenlik duvarı yapılandırmasını uçtan uca doğrulayın. IPv6, HTTP/2 veya HTTP/3 kullanmanın önkoşulu değildir.
• QUIC erişimi ve geri dönüş: HTTP/3’ü sonlandıran uçta kullanılan UDP portunun erişilebilir olması gerekir. Standart HTTPS kullanımında bu genellikle UDP/443 olur; farklı bir port duyuruluyorsa o portu kontrol edin. İstemci ağı, güvenlik duvarı ve varsa CDN kurallarını ilgili bağlantı yolu için inceleyin. UDP engellendiğinde istemcinin TCP tabanlı HTTP/2 veya HTTP/1.1’e geri dönebildiğini de test edin; HTTP/3 desteği tek başına bu geri dönüşün çalıştığını kanıtlamaz.

3. Donanım: Disk, RAM ve CPU Kaynakları

HTTP/2/3, istek ve yanıtların ağ üzerinden aktarımını daha verimli hale getirebilir; arka planda uygulamanız veritabanından yanıt almakta zorlanıyorsa, bu darboğazı tek başına gidermez. Hosting seçerken:

• Veritabanı ve dosya erişiminde ölçülen I/O ihtiyacına göre SATA veya NVMe SSD seçeneklerini karşılaştırın; NVMe adı tek başına düşük TTFB garantisi değildir.
• Yoğun trafik ve PHP tabanlı siteler için yeterli vCPU ve RAM kaynaklarını planlayın.
• Disk gecikmesini, CPU/RAM kullanımını ve planın I/O sınırlarını birlikte inceleyin. Karşılaştırma için NVMe SSD, SATA SSD ve HDD farklarını anlattığımız rehbere göz atabilirsiniz.

Yüksek IOPS gerektiren projelerde NVMe tabanlı VPS veya dedicated sunucu seçeneklerini değerlendirirken planın I/O sınırlarını da karşılaştırın; arşiv/yedek senaryolarında ise kapasite, maliyet ve geri yükleme gereksinimlerine göre farklı disk stratejileri seçilebilir.

4. CDN, Edge ve HTTP/3 Kombinasyonu

Bir CDN/edge ağı, uygun içeriği kullanıcıya yakın bir noktadan sunmak için değerlendirilebilir. HTTP/3 desteği ile önbelleğin katkısını ayrı ayrı ölçmek gerekir. Böyle bir tasarımda:

• Destekleyen istemci, CDN’nin yönlendirdiği edge noktasına QUIC bağlantısı açabilir.
• Önbellekte bulunan ve sunulmaya uygun statik dosyalar (görseller, CSS, JS) edge’den sunulur; önbellek kaçırmaları, yeniden doğrulamalar ve önbellek dışı istekler origin’e gider.
• Origin ile CDN arasındaki bağlantıda HTTP/2 kullanımı, iki ucun desteğine ve yapılandırmaya bağlıdır; istemci–CDN bağlantısının HTTP/3 olması bunu belirlemez.

Burada önemli olan, hosting sağlayıcınızın CDN ile iyi entegre olabilmesi, HTTP/2/3 ve TLS ayarlarının çakışmadan çalışacak şekilde tasarlanmış olmasıdır. CDN tasarımında cache-control, vary, Brotli/gzip ve edge cache kuralları birlikte planlanmalı; Core Web Vitals üzerindeki etki ölçülmelidir.

5. Yönetim Seviyesi: Paylaşımlı Hosting mi, VPS mi, Dedicated mı?

HTTP/2/3’ten maksimum verim almak için bazı projelerde tam kontrol gerekebilir.

• Paylaşımlı hosting: Kaynak sınırları ve yönetim ihtiyaçları uygunsa küçük ve orta ölçekli siteler için yeterli olabilir. HTTP/2 ve HTTP/3’ün origin’de mi, CDN tarafında mı etkin olduğunu kontrol edin. Özel Nginx/Apache ayarları gerekiyorsa planın bunlara izin verip vermediğini öğrenin.
• VPS: WordPress, WooCommerce, Laravel veya Node.js projelerinde sunucu yapılandırması üzerinde kontrol sağlayabilir; yönetici erişimi ve bakım sorumlulukları plana bağlıdır. Nginx/Apache/Caddy seçimini ve HTTP/3 için kullanılacak sürüm/derlemeyi üretim gereksinimlerine göre doğrulayın. Bu mimariyi planlarken VPS mi dedicated mı sorusunu da netleştirmek önemli.
• Dedicated ve colocation: Donanım ve işletim sistemi üzerinde daha fazla kontrol gereken projelerde değerlendirilebilir. Özel kernel ayarları, QUIC derlemeleri veya edge benzeri topolojiler planlanıyorsa yönetim yetkilerini, sağlayıcı ağ sınırlarını ve bakım sorumluluklarını ayrıca netleştirin; HTTP/3 kullanmak tek başına bu seviyeye geçmeyi gerektirmez.

HTTP/2 ve HTTP/3 seçeneklerini değerlendirirken, test ortamında ve kontrollü canlı trafik üzerinde karşılaştırılabilir ağ, içerik ve önbellek koşullarıyla A/B performans ölçümleri yapılabilir.

Örnek Senaryolar: HTTP/2 ve HTTP/3 Farkını Nerede Ölçebilirsiniz?

Aşağıdaki üç senaryo varsayımsaldır; belirtilen yükler örnek koşullardır, ölçülmüş müşteri sonuçları değildir.

Senaryo 1: WordPress Blog + Görsel Ağırlıklı İçerik

Durum:

• Her yazıda 8–15 arası görsel,
• Google Fonts, birkaç JS kütüphanesi (ör. slider, lightbox),
• Günde yaklaşık 10–30 bin sayfa görüntüleme.

HTTP/1.1 üzerinde bu tip bir sayfa açılırken tarayıcı, aynı anda sınırlı sayıda bağlantı açabildiği için görsellerin bir kısmı sırada bekler. HTTP/2’ye geçtiğinizde:

• Aynı origin’den gelen görseller ve statik dosyalar, akış sınırları ve bant genişliği elverdiği ölçüde tek bağlantı üzerinden çoklanabilir.
• Görsel optimizasyonu ve önbellekleme de iyileştirilmişse LCP düşebilir; kazanımın büyüklüğü, LCP öğesine ve mevcut darboğaza bağlıdır.

HTTP/3, özellikle bazı mobil ağ koşullarında ilk içerikli boyama (FCP) ve LCP sürelerini iyileştirebilir; etki gerçek kullanıcı verileriyle ölçülmelidir. Bu kazanım tek başına Google Discover veya mobil organik trafikte artış ya da istikrar garantisi değildir.

Senaryo 2: WooCommerce Mağazası, Kampanya Dönemi Trafik Artışı

Durum:

• Yoğun JS kullanan tema,
• Sepet ve ödeme adımlarında dinamik API çağrıları,
• Kampanya dönemlerinde ani trafik sıçramaları.

Kampanya anlarında eş zamanlı istekler, tarayıcı bağlantı sınırlarında veya sunucu ve uygulama kapasitesinde kuyruğa girebilir; aşırı yük zaman aşımına yol açabilir. HTTP/2 ve HTTP/3 bağlantı kullanımını iyileştirebilir, ancak sunucu kapasitesi darboğazını tek başına çözmez:

• Aynı TCP/QUIC bağlantısı üzerinden çok sayıda istek, akış ve kaynak sınırları dahilinde çoklanabilir.
• Sayfa geçişleri ve AJAX isteklerinde bağlantı kaynaklı beklemeler azalabilir; uygulama işlem süresi ayrıca ölçülmelidir.
• Core Web Vitals metriklerinin kampanya yükündeki durumu ayrıca izlenmelidir; protokol değişikliği bu metriklerin stabil kalmasını garanti etmez.

Bu tip projelerde HTTP/2/3 geçişini, ölçülen kaynak ihtiyacı ve önbellekleme katmanlarıyla birlikte değerlendirin. Paylaşımlı planın sınırları yeterliyse geçiş zorunlu değildir; özel yapılandırma gerektiğinde yönetici yetkileri doğrulanmış VPS veya dedicated seçenekleri incelenebilir. Bu varsayımsal projede PHP-FPM, Redis, MySQL ayarları ve HTTP/2/3 yapılandırması birlikte değerlendirilebilir; sepet ve ödeme gibi kullanıcıya özel yanıtlar ortak önbellekten sunulmamalıdır.

Senaryo 3: Statik Site, Dokümantasyon veya SaaS Landing Sayfası

Durum:

• Statik HTML, CSS, JS dosyaları,
• Global ziyaretçi kitlesi,
• Çok düşük backend yükü.

Bu senaryoda HTTP/2/3 + CDN kombinasyonu ile:

• HTTP/3 desteği olan istemci ve CDN arasında, ağ koşulları uygunsa QUIC bağlantı kurulumu gecikmeyi azaltabilir,
• Farklı bölgelerde LCP iyileşebilir; ancak dünya genelinde LCP < 1 saniye sonucu yalnızca protokol ve CDN seçimiyle öngörülemez,
• Googlebot için de düşük TTFB sağlandığı varsayılmamalı; tarama isteklerinin yanıt süreleri ayrıca değerlendirilmelidir.

Böyle projelerde, basit bir paylaşımlı hosting + doğru yapılandırılmış CDN + HTTP/2/3 üçlüsü, trafik hacmi ve planın kaynak sınırları uygunsa VPS’e geçmeden de yeterli performans sağlayabilir.

HTTP/2 ve HTTP/3 Desteğini Nasıl Test Edebilirsiniz?

Hosting seçimi yaparken veya mevcut altyapınızı değerlendirirken, HTTP/2 ve HTTP/3’ün gerçekten aktif olup olmadığını basit araçlarla görebilirsiniz.

• Tarayıcı geliştirici araçları: Chrome DevTools > Network sekmesinde “Protocol” sütununu açarak her istekte h2 / h3 / http/1.1 kullanıldığını görebilirsiniz. CDN varsa bu gözlem istemci–CDN bağlantısını gösterir; CDN–origin protokolünü kanıtlamaz.
• Çevrimiçi test araçları: Aracın HTTP/2, HTTP/3 ve TLS/ALPN için hangi kontrolleri yaptığını inceleyin. Sonuç, test noktasının eriştiği uç ve ağ yoluyla sınırlıdır; kendi kullanıcı ağınızda da kontrol yapın.
• curl: Önce curl --version çıktısındaki Features bölümünde HTTP2 ve HTTP3 desteğini kontrol edin. Resmi curl kılavuzuna göre HTTPS için --http2 seçeneği TLS el sıkışmasında HTTP/2 anlaşmasını dener; HTTP/1.1 sonucu tek başına sunucuda HTTP/2 bulunmadığını göstermez. HTTP/3 destekli derlemede –http3-only yalnızca HTTP/3’ü dener; –http3 ise HTTP/2 veya HTTP/1.1’e geri dönüşe izin verir. Bu nedenle yalnızca isteğin başarılı olmasına değil, sonuçta kullanılan protokole bakın; --write-out ile %{http_version} bu sürümü gösterir. Çıktıyı hata mesajı ve çıkış durumuyla birlikte okuyun.
• nghttp ve h2load: nghttp bir HTTP/2 istemcisidir; HTTP/3 testi için kullanılamaz. h2load ile HTTP/3 testi, kurulu sürümün ve derlemenin desteğine bağlıdır. Kurulu aracın yardım/sürüm çıktısını ve paket/derleme bilgilerini kontrol edin; HTTP/3 etkin derlemede –h3 seçeneği HTTP/3’ü zorlar. Yük testlerini yalnızca yetkili olduğunuz ortamda kontrollü yürütün.

Araçta HTTP/3 desteğinin bulunmaması, sunucunun HTTP/3 sunmadığını göstermez. HTTP/3 bağlantısı başarısızsa istemci desteğini, hedef uç/portu ve UDP erişimini ayrı ayrı inceleyin. Ardından UDP’nin engellendiği koşulda TCP tabanlı HTTP’ye geri dönüşü kontrol edin; geri dönüşün başarılı olması da HTTP/3 kullanıldığının kanıtı değildir.

Bu testleri, performans ölçümleriyle birlikte yürütmek için GTmetrix, PageSpeed Insights ve WebPageTest rehberimizi de kullanabilirsiniz. Protokol değişikliğinin sayfa yükleme süresine etkisini ayırt etmek için aynı sayfayı benzer cihaz, ağ ve önbellek koşullarında, diğer ayarları sabit tutarak karşılaştırın.

Hosting İçin Uygulama Planı

HTTP/2 ve HTTP/3 desteğini yalnızca bir özellik listesi maddesi olarak değil, altyapı tasarımının parçası olarak değerlendirmek gerekir. Planlama için şu sıra izlenebilir:

1. Projenin trafik profili (ülke, cihaz, mobil/desktop oranı, kampanya yoğunluğu) analiz edilir.
2. Paylaşımlı hosting, VPS, dedicated veya colocation’dan hangisinin mantıklı olacağı netleştirilir.
3. Web sunucusu (Nginx, Apache, LiteSpeed vb.) ve TLS mimarisi seçilir; HTTP/2 desteği temel bir seçim ölçütü olarak değerlendirilir; HTTP/3 ise istemci, sunucu/CDN desteği ve ağ erişimi doğrulanarak planlanır.
4. Önbellekleme katmanları (OPcache, Redis/Memcached, tam sayfa cache, CDN) kurgulanır; kullanıcıya özel yanıtlar ortak önbelleğe alınmaz.
5. Core Web Vitals hedefleri belirlenir. Canlıya çıkmadan önce laboratuvar ölçümleri ve etkileşim testleriyle darboğazlar araştırılır; bunlar gerçek kullanıcı Core Web Vitals verilerinin yerine geçmez. Yayın sonrasında LCP, INP ve CLS gerçek kullanıcı verileriyle izlenir.

Bu yaklaşım sayesinde, HTTP/2/3 geçişi tek başına yapılan bir “sihirli ayar” değil, tüm SEO ve performans stratejisinin parçası haline gelir. Eğer WordPress veya WooCommerce gibi yaygın altyapılar kullanıyorsanız, HTTP/2/3 ile birlikte object cache, tam sayfa önbellek ve CDN ayarlarını da kapsayan bütüncül rehberlerimize göz atmanız faydalı olacaktır.

Sonuç ve Yol Haritası: Bundan Sonra Ne Yapmalı?

HTTP/2 ve HTTP/3 desteği, hosting seçiminde performans açısından değerlendirilmelidir. Ancak protokol desteğinden tek başına SEO avantajı veya dezavantajı çıkarılamaz; önemli olan yapılandırmanın gerçek kullanıcı deneyimine ve ölçülen Core Web Vitals değerlerine etkisidir.

Özetlemek gerekirse:

• HTTP/2, aynı bağlantı üzerinden çoklu istek yönetimiyle TTFB ve LCP’yi iyileştirebilir; kazanç, sayfanın kaynak yapısına ve mevcut darboğazlara bağlıdır.
• HTTP/3 (QUIC), özellikle mobil ve dalgalı ağlarda, bağlantı kurulumu ve paket kaybı yönetimiyle avantaj sağlayabilir; fark gerçek ağ koşullarında ölçülmelidir.
• Google, Core Web Vitals’ı sıralama sistemlerinde kullanır; ancak iyi skorlar üst sıraları garanti etmez. Protokol geçişinin güçlü bir SEO etkisi yaratacağı veya tarama verimliliğinin sıralama kazancına dönüşeceği varsayılmamalıdır.
• Hosting seçerken sadece “HTTP/2/3 destekliyor musunuz?” demek yetmez; web sunucusu, TLS, network, disk altyapısı ve CDN entegrasyonunu birlikte değerlendirmek gerekir.

Mevcut sitenizi değerlendirirken veya yeni bir proje planlarken paylaşımlı hosting, VPS, dedicated sunucu ve colocation seçeneklerini kaynak ihtiyacı ve yönetim sorumluluklarına göre karşılaştırın. Uygulamanızın yapısına ve SEO hedeflerinize göre, hem protokol seviyesinde (HTTP/2/3, TLS 1.3) hem de uygulama tarafında (önbellek, veritabanı, CDN) uçtan uca bir mimari tasarlamak, performans ve maliyet dengesini değerlendirmeye yardımcı olur.

Sonraki adım, mevcut performansı ölçüp değişikliklerden sonra karşılaştırılabilir koşullarda yeniden değerlendirmektir. Hosting seçimi için son kontrol listesi:

• İlgili planda HTTP/2 ve HTTP/3 hangi uçta etkin; kullanılan protokol doğrulandı mı?
• Sunucu/derleme ve TLS yapılandırması uygun mu; ayar ve bakım sorumluluğu kimde?
• QUIC’in UDP portu erişilebilir mi; güvenlik duvarı/CDN yolu ve TCP tabanlı HTTP’ye geri dönüş kontrol edildi mi?
• Lokasyon, ağ kalitesi, CPU/RAM ve I/O sınırları iş yüküne uygun mu?
• CDN–origin bağlantısı ve önbellek kuralları ayrı ayrı değerlendirildi mi?
• Aynı içerik, cihaz, ağ ve önbellek koşullarında protokol karşılaştırması planlandı mı; canlıdaki LCP, INP ve CLS verileriyle birlikte TTFB de izleniyor mu?