İçerik yayınlama ağları (CDN)

İçerik yayınlama ağı kullanarak performansı artırın.

İçerik yayınlama ağları (CDN'ler), kullanıcılara kaynakları sunmak için dağıtılmış bir sunucu ağı kullanarak site performansını iyileştirir. CDN'ler sunucu yükünü azalttığından, sunucu maliyetlerini azaltır ve trafikteki ani artışlarla başa çıkmaya çok uygundur. Bu makalede CDN'lerin işleyiş şekli ele alınmış ve bir CDN kurulumu seçme, yapılandırma ve optimize etme konusunda platformdan bağımsız rehberlik sunulmaktadır.

Genel bakış

İçerik yayınlama ağı, içeriği kullanıcılara hızlı bir şekilde sunmak için optimize edilmiş sunuculardan oluşan bir ağdan oluşur. CDN'ler tartışmasız en iyi şekilde önbelleğe alınan içerik sunmayla bilinse de, CDN'ler önbelleğe alınamayan içeriklerin yayınlanmasını da iyileştirebilir. Genel olarak, sitenizin CDN tarafından ne kadar çok yayınlanması o kadar iyi olur.

CDN'lerin performans avantajları genel olarak birkaç ilkeye dayanır: CDN sunucuları, kaynak sunuculara göre daha yakındır ve bu nedenle, daha kısa bir gidiş dönüş süresi (RTT) gecikmesine sahiptir; ağ optimizasyonları, içeriğin "doğrudan" kaynak sunucudan yüklenmesinden çok daha hızlı bir şekilde CDN'lerin içerik yayınlamasına olanak tanır. Son olarak, CDN önbellekleri kaynak sunucuya gitme ihtiyacını ortadan kaldırır.

Kaynak teslimi

Mantığa aykırı gibi görünse de, kaynakları (önbelleğe alınamayanlar da dahil) sunmak için CDN kullanmak, genellikle kullanıcının kaynağı "doğrudan" sunucularınızdan yüklemesini sağlamaktan daha hızlıdır.

Kaynakları kaynaktan yayınlamak için CDN kullanıldığında, istemci ile yakındaki bir CDN sunucusu arasında yeni bir bağlantı oluşturulur. Yolculuğun geri kalanı (yani CDN sunucusu ile kaynak arasındaki veri aktarımı), CDN'nin ağı üzerinden gerçekleşir. Bu ağ, genellikle kaynakla mevcut, kalıcı bağlantıları da içerir. Bunun iki avantajı vardır: Yeni bağlantıyı kullanıcıya mümkün olduğunca yakın bir şekilde sonlandırmak, gereksiz bağlantı kurulumu maliyetlerini ortadan kaldırır (yeni bir bağlantı kurmak pahalıdır ve birden fazla gidiş dönüş gerektirir); önceden ısıtılmış bir bağlantı kullanmak, verilerin mümkün olan en yüksek işleme hızında hemen aktarılmasını sağlar.

Bazı CDN'ler, trafiği kaynağa internette yayılmış birden fazla CDN sunucusu üzerinden yönlendirerek bu durumu daha da iyileştirir. CDN sunucuları arasındaki bağlantılar, Sınır Ağ Geçidi Protokolü (BGP) tarafından belirlenen rotalar yerine güvenilir ve son derece optimize edilmiş rotalar üzerinden gerçekleşir. BGP internetin fiili yönlendirme protokolü olsa da yönlendirme kararları her zaman performans odaklı değildir. Bu nedenle, BGP tarafından belirlenen rotaların performansı büyük olasılıkla CDN sunucuları arasındaki ince ayarlanmış rotalardan daha düşük olacaktır.

Önbelleğe alma

Kaynakları CDN'nin sunucularında önbelleğe almak, bir isteğin sunulması için kaynağa tamamen gitme ihtiyacını ortadan kaldırır. Sonuç olarak, kaynak daha hızlı teslim edilir ve kaynak sunucunun yükü de azalır.

Önbelleğe kaynak ekleme

CDN önbelleklerini doldurmak için en yaygın kullanılan yöntem, CDN "pull" kaynaklarına ihtiyaç duyulduğunda sahip olmaktır. Bu yöntem, "kaynak çekme" olarak bilinir. Belirli bir kaynak önbellekten ilk kez istendiğinde CDN, kaynak sunucudan ilgili kaynağı ister ve yanıtı önbelleğe alır. Bu şekilde, önbellek içeriği, önbelleğe alınmamış ek kaynaklar istendiğinde zaman içinde birikir.

Kaynakları önbellekten kaldırma

CDN'ler, yararlı olmayan kaynakları düzenli olarak önbellekten kaldırmak için önbellekten çıkarma işlemini kullanır. Buna ek olarak, site sahipleri kaynakları açıkça kaldırmak için temizleme işlemini kullanabilir.

• Önbellekten çıkarma

  Önbelleklerin sınırlı bir depolama kapasitesi vardır. Bir önbellek kapasitesine yaklaştığında son zamanlarda erişilmeyen veya çok fazla yer kaplayan kaynakları kaldırarak yeni kaynaklara yer açar. Bu işlem önbellekten çıkarma olarak bilinir. Bir önbellekten çıkarılan kaynağın CDN ağındaki tüm önbelleklerden çıkarıldığı anlamına gelmez.

• Silme

  Tamamen silme ("önbelleği geçersiz kılma" olarak da bilinir), bir kaynağın süresinin dolmasını veya atılmasını beklemek zorunda kalmadan CDN'nin önbelleklerinden kaldırılması için kullanılan bir mekanizmadır. Bu işlem genellikle bir API aracılığıyla yürütülür. İçeriğin geri çekilmesi gereken durumlarda (örneğin, yazım hatalarının, fiyatlandırma hatalarının veya yanlış haber makalelerinin düzeltilmesi) tamamen silme işlemi kritik öneme sahiptir. Bunun yanı sıra, bir sitenin önbelleğe alma stratejisinde de önemli bir rol oynayabilir.

  Bir CDN, neredeyse anında temizlemeyi destekliyorsa dinamik içeriğin önbelleğe alınmasını yönetmek için bir mekanizma olarak temizleme yöntemi kullanılabilir: Dinamik içeriği uzun bir TTL kullanarak önbelleğe alın, ardından güncellendiğinde kaynağı tamamen silin. Bu şekilde, kaynağın ne zaman değişeceğini önceden bilmeseniz bile dinamik kaynağın önbelleğe alma süresini en üst düzeye çıkarmak mümkündür. Bu tekniğe bazen "öne çıkana kadar bekletilen önbelleğe alma" da denir.

  Kalıcı olarak silme işlemi geniş ölçekte kullanıldığında genellikle "önbellek etiketleri" veya "vekil önbellek anahtarları" olarak bilinen bir kavramla birlikte kullanılır. Bu mekanizma, site sahiplerinin bir veya daha fazla ek tanımlayıcıyı (bazen "etiketler" olarak da adlandırılır) önbelleğe alınmış bir kaynakla ilişkilendirmesine olanak tanır. Bu etiketler daha sonra son derece ayrıntılı bir silme işlemi gerçekleştirmek için kullanılabilir. Örneğin, sitenizin alt bilgisini içeren tüm kaynaklara (örneğin /about, /blog) bir "altbilgi" etiketi ekleyebilirsiniz. Altbilgi güncellendiğinde, CDN'nize "footer" etiketiyle ilişkili tüm kaynakları tamamen silmesi için talimat verin.

Önbelleğe alınabilir kaynaklar

Bir kaynağın önbelleğe alınması gerekip gerekmediğini ve nasıl önbelleğe alınması gerektiği, kaynağın herkese açık mı yoksa gizli mi, statik mi yoksa dinamik mi olduğuna bağlıdır.

Özel ve herkese açık kaynaklar

• Özel Kaynaklar

  Özel kaynaklar, tek bir kullanıcıya yönelik veriler içerir ve bu nedenle bir CDN tarafından önbelleğe alınmamalıdır. Özel kaynaklar, Cache-Control: private başlığıyla gösterilir.

• Herkese Açık Kaynaklar

  Herkese açık kaynaklar, kullanıcıya özel bilgiler içermez ve bu nedenle bir CDN tarafından önbelleğe alınabilir. Cache-Control: no-store veya Cache-Control: private başlığı bulunmayan kaynaklar, CDN tarafından önbelleğe alınabilir olarak kabul edilebilir. Herkese açık bir kaynağın önbelleğe alınabileceği süre, öğenin ne sıklıkta değiştiğine bağlıdır.

Dinamik ve statik içerik

• Dinamik içerik

  Dinamik içerik, sık sık değişen içeriktir. API yanıtı ve mağaza ana sayfası, bu içerik türüne örnek olarak verilebilir. Ancak, bu içeriğin sık sık değişmesi, önbelleğe alınmasına engel değildir. Trafik yoğun olduğunda bu yanıtların çok kısa süreler için (örneğin, 5 saniye) önbelleğe alınması, kaynak sunucudaki yükü önemli ölçüde azaltabilir ve verilerin güncelliği üzerinde minimum etkiye sahip olur.

• Statik içerik

  Statik içerik nadiren değişir. Resimler, videolar ve sürümü oluşturulan kitaplıklar genellikle bu içerik türüne örnektir. Statik içerik değişmediği için uzun bir Geçerlilik Süresi (TTL) ile (örneğin, 6 ay veya 1 yıl) önbelleğe alınmalıdır.

CDN seçme

CDN seçilirken genellikle performans en önemli hususlardan biridir. Bununla birlikte, CDN'nin sunduğu diğer özelliklerin (örneğin, güvenlik ve analiz özellikleri) yanı sıra CDN'nin fiyatlandırması, desteği ve ilk katılım, CDN seçilirken dikkate alınması gereken önemlidir.

Performans

Genel olarak, CDN'nin performans stratejisi, gecikmeyi en aza indirme ile önbellek isabet oranını en üst düzeye çıkarma arasındaki denge açısından düşünülebilir. Çok sayıda varlık noktasına (dönemden döneme) sahip CDN'ler daha düşük gecikme sağlayabilir, ancak trafiğin daha fazla önbellek arasında bölünmesi nedeniyle daha düşük önbellek isabet oranlarıyla karşılaşabilir. Buna karşılık, daha az PoP'ye sahip CDN'ler coğrafi olarak kullanıcılardan daha uzakta bulunabilir, ancak daha yüksek önbellek isabet oranları sağlayabilir.

Bu dengenin bir sonucu olarak, bazı CDN'ler önbelleğe alma için katmanlı bir yaklaşım kullanır: Kullanıcılara yakın konumdaki PoP'ler ("uç önbellekleri" olarak da bilinir), daha yüksek önbellek isabet oranlarına sahip merkezi dönemlerle desteklenir. Bir uç önbelleği kaynak bulamadığında kaynak için merkezi bir Dönemden döneme bakar. Bu yaklaşım, kaynağın CDN önbelleğinden sunulması ihtimalini artırmak için biraz daha fazla gecikme sağlar. Ancak bu, uç önbelleği kullanmayabilir.

Gecikmeyi en aza indirmek ve önbellek isabet oranını en üst düzeye çıkarmak arasındaki fark, bir spektrumdur. Her açıdan daha iyi olan belirli bir yaklaşım yoktur; ancak, sitenizin yapısına ve kullanıcı tabanına bağlı olarak, bu yaklaşımlardan birinin diğerinden önemli ölçüde daha iyi performans sağladığını görebilirsiniz.

CDN performansının coğrafyaya, günün saatine ve hatta güncel olaylara bağlı olarak önemli ölçüde değişebileceğini de belirtmek isteriz. Bir CDN'nin performansı üzerinde kendi araştırmanızı yapmak her zaman iyi bir fikir olsa da, bir CDN'den elde edeceğiniz tam performansı tahmin etmek zor olabilir.

Largest Contentful Paint (LCP) üzerindeki etkiler

Bu makalede daha önce belirtildiği gibi, CDN'nin birincil amacı, kaynakları kullanıcılara daha yakın olan sunuculara dağıtarak gecikmeyi azaltmaktır. Bu nedenle, CDN'nin birincil avantajı yükleme performansını iyileştirmesidir. Özellikle, web sitenizin sunucu tarafı mimarisine CDN eklenirken kaynağın İlk Bayt Zamanı (TTFB) önemli ölçüde iyileştirilebilir.

TTFB, kullanıcı odaklı bir performans metriği olmasa da kullanıcı odaklı bir metrik olan Largest Contentful Paint (LCP) ile sorunları teşhis etmek için önemli bir metriktir.

CDN'ler, hem doküman yayınlamayı (bağlantı kurulumunda ve dokümanı önbelleğe almada TTFB'yi azaltarak) iyileştirebildikleri için hem de LCP öğesini oluşturmak için gereken statik kaynakların yayınlanmasını iyileştirerek LCP'yi iyileştirmede özellikle etkilidir.

Ek özellikler

CDN'ler genellikle temel CDN tekliflerine ek olarak çok çeşitli özellikler sunar. Yaygın olarak sunulan özellikler arasında yük dengeleme, görüntü optimizasyonu, video akışı, sınır bilişim ve güvenlik ürünleri bulunur.

CDN'yi ayarlama ve yapılandırma

İdeal olarak, sitenizin tamamını sunmak için bir CDN kullanmanız gerekir. Genel olarak, bunun kurulum işlemi bir CDN sağlayıcısına kaydolmayı ve ardından CNAME DNS kaydınızın CDN sağlayıcısını işaret edecek şekilde güncellenmesini içerir. Örneğin, www.example.com için CNAME kaydı example.my-cdn.com URL'sini işaret ediyor olabilir. Bu DNS değişikliğinin bir sonucu olarak, sitenize gelen trafik CDN üzerinden yönlendirilecek.

Tüm kaynakları sunmak için CDN kullanmak mümkün değilse CDN'yi yalnızca kaynakların bir alt kümesini (örneğin, yalnızca statik kaynakları) sunacak şekilde yapılandırabilirsiniz. Bunu, yalnızca CDN tarafından sunulması gereken kaynaklar için kullanılacak ayrı bir CNAME kaydı oluşturarak yapabilirsiniz. Örneğin, example.my-cdn.com adresini gösteren bir static.example.com CNAME kaydı oluşturabilirsiniz. CDN tarafından sunulan kaynakların URL'lerini, oluşturduğunuz static.example.com alt alan adına işaret edecek şekilde yeniden yazmanız gerekir.

CDN'niz bu noktada ayarlanır, ancak muhtemelen yapılandırmanızda verimsizlikler olacaktır. Bu makalenin sonraki iki bölümünde, önbellek isabet oranını artırarak ve performans özelliklerini etkinleştirerek CDN'nizden en iyi şekilde nasıl yararlanabileceğiniz açıklanmaktadır.

Önbellek isabet oranını iyileştirme

Etkili bir CDN kurulumu, önbellekten mümkün olduğunca fazla kaynak sunar. Bu genellikle önbellek isabet oranı (CHR) ile ölçülür. Önbellek isabet oranı, belirli bir zaman aralığı boyunca önbellek isabetlerinin toplam istek sayısına bölünmesiyle elde edilen oran olarak tanımlanır.

Yeni başlatılan bir önbelleğin CHR değeri 0 olur ancak önbellek kaynaklarla dolduruldukça bu değer artar. %90'lık bir DO değeri çoğu site için iyi bir hedeftir. CDN sağlayıcınız, CHR'nizle ilgili analizler ve raporlar sağlamalıdır.

CHR'yi optimize ederken doğrulanması gereken ilk şey, önbelleğe alınabilir tüm kaynakların doğru süre boyunca önbelleğe alınması ve önbelleğe alınmasıdır. Bu, tüm siteler tarafından uygulanması gereken basit bir değerlendirmedir.

Genel olarak CHR optimizasyonunun bir sonraki seviyesi, mantıksal olarak eşdeğer sunucu yanıtlarının ayrı olarak önbelleğe alınmamasını sağlamak için CDN ayarlarınızda hassas düzenlemeler yapmaktır. Bu durum; sorgu parametreleri, çerezler ve istek başlıkları gibi faktörlerin önbelleğe alma üzerindeki etkisinden dolayı yaygın olarak görülen verimsizliklerden biridir.

İlk denetim

Çoğu CDN, önbellek analizi sağlar. Buna ek olarak, bir sayfanın tüm statik kaynaklarının doğru süre boyunca önbelleğe alındığını hızlı bir şekilde doğrulamak için WebPageTest ve Lighthouse gibi araçlar da kullanılabilir. Bu işlem, her bir kaynağın HTTP Önbellek üstbilgileri kontrol edilerek gerçekleştirilir. Bir kaynağı uygun maksimum Geçerlilik Süresi (TTL) kullanarak önbelleğe almak, gelecekte gereksiz kaynak getirmeleri önleyerek DO'yu artırır.

Bir kaynağın CDN tarafından önbelleğe alınması için en azından bu üstbilgilerden birinin ayarlanması gerekir:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Ayrıca, bir kaynağın CDN tarafından önbelleğe alınıp alınmayacağını veya nasıl önbelleğe alınacağını etkilemese de, Cache-Control: immutable yönergesinin de ayarlanması iyi bir uygulamadır.Cache-Control: immutable, bir kaynağın "güncellik ömrü boyunca güncellenmeyeceğini" belirtir. Sonuç olarak, tarayıcı kaynağı tarayıcı önbelleğinden sunarken yeniden doğrulamaz, böylece gereksiz bir sunucu isteğini ortadan kaldırır. Maalesef bu yönerge yalnızca Firefox ve Safari tarafından desteklenmekte, Chromium tabanlı tarayıcılarda desteklenmemektedir. Bu sorun, Cache-Control: immutable için Chromium desteğini takip etmektedir. Bu soruna yıldız eklemek, bu özellik için desteğin teşvik edilmesine yardımcı olabilir.

HTTP önbelleğe almayla ilgili daha ayrıntılı bir açıklama için Gereksiz ağ isteklerini HTTP Önbelleği ile önleme başlıklı makaleyi inceleyin.

İnce ayar

CDN önbelleklerinin işleyişine dair biraz basitleştirilmiş bir açıklama, bir kaynağın URL'sinin kaynağı önbelleğe almak ve önbellekten almak için anahtar olarak kullanılmasıdır. Pratikte bu, hâlâ oldukça doğru olmakla birlikte, istek başlıkları ve sorgu parametreleri gibi öğelerin etkisi nedeniyle biraz karmaşıktır. Sonuç olarak, istek URL'lerini yeniden yazmak, hem DO'yu en üst düzeye çıkarmak hem de kullanıcılara doğru içeriğin sunulmasını sağlamak açısından önemli bir tekniktir. Düzgün yapılandırılmış bir CDN örneği, aşırı ayrıntılı önbelleğe alma (CHR'a zarar verir) ile yeterince ayrıntılı önbelleğe alma (kullanıcılara yanlış yanıtların sunulmasına neden olur) arasında doğru dengeyi sağlar.

Sorgu parametreleri

Varsayılan olarak CDN'ler bir kaynağı önbelleğe alırken sorgu parametrelerini dikkate alır. Bununla birlikte, sorgu parametresi işlemede yapılan küçük düzenlemelerin CHR üzerinde önemli bir etkisi olabilir. Örneğin:

• Gereksiz sorgu parametreleri

  Varsayılan olarak bir CDN, aynı temel kaynak olmalarına rağmen example.com/blog ve example.com/blog?referral_id=2zjk öğelerini ayrı ayrı önbelleğe alır. Bu sorun, CDN'nin yapılandırmasını referral\_id sorgu parametresini yoksayacak şekilde ayarlayarak düzeltildi.

• Sorgu parametresi sırası

  CDN, example.com/blog?id=123&query=dogs öğesini example.com/blog?query=dogs&id=123 ürününden ayrı olarak önbelleğe alır. Çoğu site için sorgu parametresi sırası önemli değildir; dolayısıyla, CDN'yi sorgu parametrelerini sıralayacak şekilde yapılandırmak (böylece, sunucu yanıtını önbelleğe almak için kullanılan URL'yi normalleştirmek) CHR'ı artırır.

Değiştir

Vary yanıt başlığı, önbelleklere belirli bir URL'ye karşılık gelen sunucu yanıtının istekte ayarlanan başlıklara (örneğin, Kabul-Dil veya Kabul-Encoding istekleri) bağlı olarak değişebileceğini bildirir. Sonuç olarak, CDN'ye bu yanıtları ayrı olarak önbelleğe alması talimatını verir. Vary üst bilgisi CDN'ler tarafından geniş ölçüde desteklenmez ve başka şekilde önbelleğe alınabilen bir kaynağın önbellekten sunulmamasına neden olabilir.

Vary başlığı yararlı bir araç olsa da, uygunsuz kullanımın CHR'a zarar vermesi gerekir. Buna ek olarak, Vary kullanıyorsanız istek başlıklarını normalleştirmek CHR'yi iyileştirmeye yardımcı olur. Örneğin, normalleştirme olmadan Accept-Language: en-US ve Accept-Language: en-US,en;q=0.9 istek başlıkları, içerikleri büyük olasılıkla aynı olsa bile iki ayrı önbellek girişi oluşturur.

kurabiyeler

Çerezler, Cookie başlığı aracılığıyla isteklerde, yanıtlarda ise Set-Cookie başlığı aracılığıyla ayarlanır. Önbellekler genellikle bu başlığı içeren sunucu yanıtlarını önbelleğe almayacağı için Set-Cookie üstbilgisinin gereksiz kullanımından kaçınılmalıdır.

Performans özellikleri

Bu bölümde, CDN'ler tarafından temel ürün tekliflerinin bir parçası olarak yaygın şekilde sunulan performans özellikleri açıklanmaktadır. Birçok site bu özellikleri etkinleştirmeyi unutur. Bu nedenle, kolay performans kazançlarını kaybetmiş olur.

Sıkıştırma

Tüm metin tabanlı yanıtlar gzip veya Brotli ile sıkıştırılmalıdır. Seçeneğiniz varsa gzip'te Brotli'yi seçin. Brotli, daha yeni bir sıkıştırma algoritmasıdır ve gzip'e kıyasla daha yüksek sıkıştırma oranları sağlayabilir.

Brotli sıkıştırması için iki tür CDN desteği vardır: "Kaynaktan Brotli" ve "otomatik Brotli sıkıştırma".

Menşe

Kaynaktan Brotli, bir CDN'nin kaynak tarafından Brotli ile sıkıştırılan kaynakları sunmasıdır. Bu, tüm CDN'lerin anında destekleyebilmesi gereken bir özellik gibi görünse de, CDN'nin belirli bir URL'ye karşılık gelen kaynağın birden fazla sürümünü (diğer bir deyişle, gzip veya Brotli ile sıkıştırılmış sürümleri) önbelleğe alabilmesini gerektirir.

Otomatik Brotli sıkıştırması

Otomatik Brotli sıkıştırması, kaynakların CDN tarafından Brotli tarafından sıkıştırılmasıdır. CDN'ler hem önbelleğe alınabilir hem de önbelleğe alınamayan kaynakları sıkıştırabilir.

Bir kaynak ilk kez istendiğinde, "yeterince iyi" sıkıştırma kullanılarak (ör. Brotli-5) sunulur. Bu sıkıştırma türü, hem önbelleğe alınabilir hem de önbelleğe alınamayan kaynaklar için geçerlidir.

Bir kaynak önbelleğe alınabiliyorsa CDN, kaynağı daha güçlü ancak çok daha yavaş bir sıkıştırma düzeyinde (ör. Brotli-11) sıkıştırmak için çevrimdışı işlemeyi kullanır. Bu sıkıştırma işlemi tamamlandıktan sonra, daha sıkıştırılmış sürüm önbelleğe alınır ve sonraki istekler için kullanılır.

Sıkıştırmayla ilgili en iyi uygulamalar

Performansı en üst düzeye çıkarmak isteyen siteler, hem kaynak sunucularında hem de CDN'de Brotli sıkıştırması uygulamalıdır. Kaynaktaki Brotli sıkıştırması, önbellekten sunulamayan kaynakların aktarım boyutunu en aza indirir. İstek sunmadaki gecikmeleri önlemek için kaynak, dinamik kaynakları oldukça konservatif bir sıkıştırma düzeyi (ör. Brotli-4) kullanarak sıkıştırmalıdır. Statik kaynaklar, Brotli-11 kullanılarak sıkıştırılabilir. Kaynak, Brotli'yi desteklemiyorsa dinamik kaynakları sıkıştırmak için gzip-6, statik kaynakları sıkıştırmak için gzip-9 kullanılabilir.

TLS 1.3

TLS 1.3, HTTPS tarafından kullanılan şifreleme protokolü olan Taşıma Katmanı Güvenliği (TLS) hizmetinin en yeni sürümüdür. TLS 1.3, TLS 1.2'ye kıyasla daha iyi gizlilik ve performans sunar.

TLS 1.3, TLS el sıkışmasını iki gidiş dönüşten bire kısaltır. HTTP/1 veya HTTP/2 kullanan bağlantılar için TLS el sıkışmasının bir döngüye kısaltılması, bağlantı kurulumu süresini %33 oranında etkili bir şekilde azaltır.

HTTP/2 ve HTTP/3

Hem HTTP/2 hem de HTTP/3, HTTP/1'e kıyasla performans avantajları sunar. HTTP/3, bu iki yöntemden daha fazla potansiyel performans avantajı sunar. HTTP/3 henüz tam olarak standartlaştırılmadı ancak bu işlem gerçekleştikten sonra yaygın olarak desteklenecektir.

HTTP/2

CDN'niz HTTP/2'yi zaten varsayılan olarak etkinleştirmediyse bunu etkinleştirmeniz önerilir. HTTP/2, HTTP/1'e kıyasla birçok performans avantajı sağlar ve başlıca tarayıcıların tümü tarafından desteklenir. HTTP/2'nin performans özellikleri arasında çoklulama, akış önceliklendirme ve üstbilgi sıkıştırma yer alır.

• Multiplex

  Multiplex, HTTP/2'nin muhtemelen en önemli özelliğidir. Multiplex, tek bir TCP bağlantısının aynı anda birden fazla istek-yanıt çifti sunmasını sağlar. Bu, gereksiz bağlantı kurulumunun ek yükünü ortadan kaldırır. Bir tarayıcının belirli bir zamanda açabileceği bağlantı sayısı sınırlı olduğundan, bu aynı zamanda tarayıcının artık paralel olarak daha fazla sayfanın daha fazla kaynağını isteyebileceği anlamına da gelir. Multiplex, birleştirme ve model sayfaları gibi HTTP/1 optimizasyonlarına olan ihtiyacı teorik olarak ortadan kaldırır. Ancak, daha büyük dosyaların daha iyi sıkıştırılması sayesinde, pratikte bu teknikler geçerliliğini koruyacaktır.

• Akış önceliklendirme

  Multiplex, birden fazla eşzamanlı akışa olanak tanır; akış önceliklendirme ise bu akışların her birinin göreli önceliğini bildirmek için bir arayüz sağlar. Bu, sunucunun ilk olarak istenmemiş olsa bile en önemli kaynakları önce göndermesine yardımcı olur.

Akış önceliği, tarayıcı tarafından bir bağımlılık ağacı aracılığıyla ifade edilir ve yalnızca bir tercih ifadesidir. Diğer bir deyişle, sunucunun, tarayıcı tarafından sağlanan öncelikleri karşılaması (veya dikkate alma zorunluluğu) yoktur. Akış önceliklendirme, bir CDN aracılığıyla daha fazla site sunulduğunda daha etkili hale gelir.

HTTP/2 kaynak önceliklendirmenin CDN uygulamaları büyük farklılıklar gösterir. CDN'nizin HTTP/2 kaynak önceliklendirmesini tamamen ve düzgün bir şekilde destekleyip desteklemediğini belirlemek için HTTP/2 Henüz Hızlı mı? başlıklı makaleye göz atın.

CDN örneğinizi HTTP/2'ye geçirmek büyük ölçüde bir anahtarı çevirmeyi gerektirse de üretimde etkinleştirmeden önce bu değişikliği kapsamlı bir şekilde test etmek önemlidir. HTTP/1 ve HTTP/2, istek ve yanıt başlıkları için aynı kuralları kullanır ancak bu kurallara uyulmadığında HTTP/2 çok daha az esnektir. Sonuç olarak, başlıklara ASCII olmayan veya büyük harfli karakterler eklemek gibi teknik olmayan uygulamalar, HTTP/2 etkinleştirildikten sonra hatalara neden olabilir. Bu durumda, tarayıcının kaynağı indirme girişimi başarısız olur. Başarısız indirme denemesi, Geliştirici Araçları'nın "Ağ" sekmesinde görünür. Ayrıca, konsolda "ERR_HTTP2_PROTOCOL_ERROR" hata mesajı görüntülenir.

HTTP/3

HTTP/3, HTTP/2'nin yerini alır. Eylül 2020 itibarıyla, tüm önemli tarayıcılarda HTTP/3 için deneysel destek bulunmaktadır ve bazı CDN'ler bu desteği desteklemektedir. Performans, HTTP/3'ün HTTP/2'ye göre birincil avantajıdır. Özellikle HTTP/3, bağlantı düzeyinde satır içi engellemeyi ortadan kaldırır ve bağlantı kurulumu süresini kısaltır.

• Satır başı engellemenin kaldırılması

  HTTP/2, birden fazla veri akışını aynı anda iletmek için tek bir bağlantının kullanılmasına olanak tanıyan Multiplex özelliğini kullanıma sundu. Ancak HTTP/2'de tek bir atlanan paket, bir bağlantıdaki tüm akışları engeller (head-of-line engelleme olarak bilinen bir olgu). HTTP/3 ile bırakılan paket, yalnızca tek bir akışı engeller. Bu iyileştirme büyük ölçüde TCP yerine UDP (HTTP/3 QUIC üzerinden UDP kullanır) kullanılan HTTP/3'ten kaynaklanmaktadır. Bu, HTTP/3'ü özellikle tıkanık veya kayıplı ağlar üzerinden veri aktarımı için yararlı hale getirir.

• Daha kısa bağlantı kurulumu süresi

  HTTP/3, TLS 1.3 kullanır ve bu nedenle performans avantajlarını paylaşır: Yeni bir bağlantı kurmak için yalnızca tek bir gidiş gerekir ve mevcut bağlantıyı devam ettirmek için herhangi bir gidiş dönüş gerekmez.

HTTP/3, zayıf ağ bağlantılarında kullanıcılar üzerinde en büyük etkiyi yaratacaktır: Bunun nedeni yalnızca HTTP/3'ün paket kaybını öncekilerden daha iyi işlemesi değil, aynı zamanda yüksek gecikmeli ağlarda 0-RTT veya 1-RTT bağlantı kurulumundan kaynaklanan mutlak zaman tasarrufunun daha fazla olmasıdır.

Resim optimizasyonu

CDN resim optimizasyonu hizmetleri genellikle, görüntü aktarım boyutunu azaltmak için otomatik olarak uygulanabilen resim optimizasyonlarına odaklanır. Örneğin: EXIF verilerini çıkarma, kayıpsız sıkıştırma uygulama ve resimleri daha yeni dosya biçimlerine (ör. WebP) dönüştürme. Resimler, medyan web sayfasındaki aktarım baytlarının yaklaşık% 50'sini oluşturduğundan resimleri optimize etmek sayfa boyutunu önemli ölçüde azaltabilir.

Küçültme

Küçültme, gereksiz karakterleri JavaScript, CSS ve HTML'den kaldırır. Küçültmenin CDN yerine kaynak sunucuda yapılması tercih edilir. Site sahipleri, küçültülecek kod hakkında daha fazla bağlama sahip olur ve bu nedenle, CDN'ler tarafından kullanılanlara kıyasla genellikle daha agresif küçültme teknikleri kullanabilirler. Bununla birlikte, kaynaktaki kodu küçültmek mümkün değilse CDN'ye göre küçültme iyi bir alternatiftir.

Sonuç

• CDN kullanın: CDN'ler kaynakları hızlı bir şekilde yayınlar, kaynak sunucudaki yükü azaltır ve ani trafik artışlarıyla başa çıkmaya yardımcı olur.
• İçeriği mümkün olduğunca agresif bir şekilde önbelleğe alın: Hem statik hem de dinamik içerik, farklı sürelerde de olsa önbelleğe alınabilir ve önbelleğe alınmalıdır. İçeriği en iyi şekilde önbelleğe aldığınızdan emin olmak için sitenizi düzenli olarak denetleyin.
• CDN performans özelliklerini etkinleştirin: Brotli, TLS 1.3, HTTP/2 ve HTTP/3 gibi özellikler performansı daha da artırır.