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

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

Katie Hempenius

İçerik yayınlama ağları (CDN'ler), kullanıcılara kaynak sağlamak için dağıtılmış bir sunucu ağı kullanarak site performansını iyileştirir. CDN'ler sunucu yükünü azalttığı için sunucu maliyetlerini azaltır ve ani trafik artışlarını yönetmeye uygundur. Bu makalede CDN'lerin nasıl çalıştığı anlatılmakta ve bir CDN kurulumunun seçimi, yapılandırması ve optimizasyonu hakkında platformdan bağımsız rehberlik sağlanmaktadır.

Genel bakış

İçerik yayınlama ağı, içeriği kullanıcılara hızlı bir şekilde dağıtmak için optimize edilmiş bir sunucu ağından oluşur. CDN'ler muhtemelen önbelleğe alınmış içerikleri sunmalarıyla bilinse de, önbelleğe alınamayan içeriklerin yayınlanmasını da iyileştirebilir. Genel olarak, siteniz CDN'niz tarafından ne kadar çok yayınlanıyorsa o kadar iyidir.

CDN'lerin performans avantajları genel olarak birkaç ilkeden kaynaklanır: CDN sunucuları, kullanıcılara kaynak sunuculardan daha yakındır ve bu nedenle gidiş dönüş süresi (RTT) gecikmesi daha kısadır. Ağ optimizasyonları, CDN'lerin içeriği, içeriğin "doğrudan" kaynak sunucudan yüklenmesine kıyasla daha hızlı yayınlamasını sağlar. Son olarak, CDN önbellekleri isteğin kaynak sunucuya gitme ihtiyacını ortadan kaldırır.

Anahtar terim: Kaynak sunucu, CDN'nin içerik aldığı sunucuyu ifade eder.

Kaynak yayınlama

Kolay değil gibi görünse de, kaynakları (önbelleğe alınamayanlar dahil) sunmak için CDN kullanmak genellikle kullanıcının kaynağı sunucularınızdan "doğrudan" yüklemekten daha hızlı olacaktır.

Kaynaktan kaynak yayınlamak için bir CDN kullanıldığında, istemci ile yakındaki bir CDN sunucusu arasında yeni bir bağlantı kurulur. Yolculuğun geri kalanı (diğer bir deyişle, CDN sunucusu ile kaynak arasındaki veri aktarımı), CDN'nin ağı üzerinden gerçekleşir ve bu ağ genellikle kaynakla mevcut, kalıcı bağlantıları içerir. Bunun iki avantajı vardır: Yeni bağlantıyı kullanıcıya mümkün olduğunca yakın tutmak gereksiz bağlantı kurulumu maliyetlerini ortadan kaldırır (yeni bağlantı kurmak pahalıdır ve birden fazla kez tekrar yapılmasını gerektirir); önceden ısıtılmış bir bağlantı kullanmak ise verilerin mümkün olan en yüksek işleme hızında hemen aktarılmasına olanak tanır.

Bazı CDN'ler, trafiği kaynağa yayılmış birden fazla CDN sunucusu aracılığıyla kaynağa yönlendirerek bunu 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 yüksek düzeyde 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, CDN sunucuları arasındaki ince ayar yapılmış rotalardan daha düşük performans gösterme olasılığı yüksektir.

Önbelleğe alma

Bir CDN'nin sunucularında kaynakları önbelleğe almak, bir isteğin sunulmak için kaynağa tamamen gitme ihtiyacını ortadan kaldırır. Böylece kaynak daha hızlı bir şekilde teslim edilir ve bu da kaynak sunucu üzerindeki yükü azaltır.

Önbelleğe kaynak ekleme

CDN önbelleklerini doldurmak için en yaygın olarak kullanılan yöntem, CDN kaynaklarına ihtiyaç duyulduğu gibi sahip olmaktır. Buna "kaynak çekme" denir. Önbellekten belirli bir kaynak ilk kez istendiğinde CDN, kaynak sunucudan bu kaynağı ister ve yanıtı önbelleğe alır. Bu şekilde, zaman içinde önbelleğe alınmamış ek kaynaklar istendikçe önbelleğin içeriği birikir.

Kaynakları önbellekten kaldırma

CDN'ler, çok faydalı olmayan kaynakları önbellekten düzenli olarak kaldırmak için önbellekten çıkarma özelliğini kullanır. Ayrıca, site sahipleri kaynakları açıkça kaldırmak için temizleme özelliğini kullanabilir.

• Önbellekten çıkarma

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

• Silme

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

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

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

Önbelleğe alınabilir kaynaklar

Bir kaynağın önbelleğe alınıp alınmayacağı ve önbelleğe alınma şekli, o kaynağın herkese açık veya özel; statik ya da dinamik olmasına 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, 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ığı olmayan bir kaynak, 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, içeriğin önbelleğe alınmasını engellemez. Trafiğin yoğun olduğu zamanlarda bu yanıtları çok kısa sürelerle (örneğin, 5 saniye) önbelleğe almak, kaynak sunucudaki yükü önemli ölçüde azaltabilir ve veri güncelliği üzerinde en az etkiye sahip olabilir.

• 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 önbelleğe alınmalıdır (örneğin, 6 ay veya 1 yıl).

CDN seçme

CDN seçilirken genellikle en önemli unsur performanstır. Bununla birlikte, CDN'nin sunduğu diğer özelliklerin (ör. güvenlik ve analiz özellikleri) yanı sıra CDN'nin fiyatlandırması, desteği ve ilk katılımı, CDN seçerken dikkate alınması açısından önemlidir.

Performans

Bir CDN'nin performans stratejisi, yüksek bir düzeyde gecikmeyi en aza indirme ile önbellek isabet oranını en üst düzeye çıkarma arasındaki denge olarak düşünülebilir. Çok sayıda varlık noktasına (PoP) sahip CDN'ler daha düşük gecikme sağlayabilir ancak trafiğin daha fazla önbelleğe bölünmesi nedeniyle daha düşük önbellek isabet oranları elde edebilir. Buna karşılık, daha az PoP'ye sahip CDN'ler coğrafi olarak kullanıcılardan daha uzak bir konumda bulunabilir ancak daha yüksek önbellek isabet oranları elde edebilir.

Bu dengenin sonucunda, bazı CDN'ler önbelleğe alma için katmanlı bir yaklaşım kullanır: Kullanıcılara yakın konumdaki PoP'ler ("kenar önbellekleri" olarak da bilinir) daha yüksek önbellek isabet oranlarına sahip merkezi PoP'lerle desteklenir. Uç önbellek, kaynağı bulamadığında kaynak için merkezi bir PoP'ye bakar. Bu yaklaşım, kaynağın CDN önbelleğinden sunulabilmesi olasılığını artırmak için biraz daha fazla gecikme sağlar (uç önbellek olmasa da).

Gecikmeyi en aza indirme ve önbellek isabet oranını en üst düzeye çıkarma arasındaki denge çeşitli seçeneklerdir. Hiçbir yaklaşım evrensel olarak daha iyi değildir. Ancak, sitenizin ve kullanıcı tabanının niteliğine bağlı olarak, bu yaklaşımlardan birinin diğerinden önemli ölçüde daha iyi performans sağladığını görebilirsiniz.

CDN performansının konuma, günün saatine ve hatta güncel etkinliklere bağlı olarak önemli ölçüde farklılık gösterebileceğini de unutmayın. Bir CDN'nin performansı hakkında kendi araştırmanızı yapmak her zaman iyi bir fikir olsa da, 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 coğrafi olarak daha yakın olan sunuculara dağıtarak gecikmeyi azaltmaktır. Bu nedenle, CDN'nin birincil avantajı yükleme performansını iyileştirmesidir. Özellikle, bir kaynağın İlk Bayt Zamanı (TTFB), web sitenizin sunucu tarafı mimarisine bir CDN eklerken önemli ölçüde iyileştirilebilir.

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

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

Ek özellikler

CDN'ler, temel CDN tekliflerine ek olarak genellikle ç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 yer alır.

CDN oluşturma ve yapılandırma

İdeal olarak sitenizin tamamına hizmet vermek için bir CDN kullanmanız gerekir. Genel olarak bunun kurulum işlemi, bir CDN sağlayıcısıyla kaydolmanız ve ardından CNAME DNS kaydınızı CDN sağlayıcısını işaret edecek şekilde güncellemeyi içerir. Örneğin, www.example.com için CNAME kaydı example.my-cdn.com adresini gösteriyor olabilir. Bu DNS değişikliğinin bir sonucu olarak, sitenize gelen trafik CDN üzerinden yönlendirilecektir.

Tüm kaynakları sunmak için CDN kullanmak uygun bir seçenek değilse CDN'yi, kaynakların yalnızca bir alt kümesini (ör. yalnızca statik kaynaklar) sunacak şekilde yapılandırabilirsiniz. Bu işlemi, 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 işaret eden 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 aşamada ayarlanacak olsa da yapılandırmanızda verimsizlikler olabilir. Bu makalenin sonraki iki bölümünde, önbellek isabet oranını artırarak ve performans özelliklerini etkinleştirerek CDN'nizden nasıl en iyi şekilde yararlanabileceğiniz açıklanmaktadır.

Önbellek isabet oranını iyileştirme

Etkili bir CDN kurulumu, önbellekten mümkün olduğunca çok kaynak sunar. Bu metrik genellikle önbellek isabet oranı (CHR) ile ölçülür. Önbellek isabet oranı, belirli bir zaman aralığı sırasında önbellek isabetlerinin sayısının 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. DO'nun% 90 olması, çoğu site için iyi bir hedeftir. CDN sağlayıcınız, CHR'nizle ilgili analizleri ve raporları size sağlamalıdır.

CHR'yi optimize ederken yapılacak ilk şey, önbelleğe alınabilir tüm kaynakların doğru süre için önbelleğe alınması ve önbelleğe alınmasıdır. Bu, tüm sitelerin yapması gereken basit bir değerlendirmedir.

Geniş anlamda, CHR optimizasyonunun bir sonraki düzeyi, mantıksal olarak eşdeğer sunucu yanıtlarının ayrı olarak önbelleğe alınmadığından emin olmak için CDN ayarlarınızda hassas düzenlemeler yapmaktır. Bu durum; sorgu parametreleri, çerezler ve istek üstbilgileri gibi faktörlerin önbelleğe alma üzerindeki etkisiyle ortaya çıkan yaygın bir verimsizlik sorunudur.

İlk denetim

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

Bir kaynağın CDN tarafından önbelleğe alınması için en azından şu başlıklardan birinin ayarlanması gerekir:

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

Ayrıca, kaynağın CDN tarafından önbelleğe alınıp alınmadığını veya nasıl önbelleğe alınacağını etkilemese de, Cache-Control: immutable yönergesini ayarlamak da iyi bir uygulamadır.Cache-Control: immutable ifadesi, bir kaynağın "yenilik ömrü boyunca güncellenmeyeceğini" belirtir. Sonuç olarak tarayıcı, kaynağı tarayıcı önbelleğinden sunarken yeniden doğrulamaz ve böylece gereksiz sunucu isteğini ortadan kaldırır. Maalesef bu yönerge yalnızca Firefox ve Safari tarafından destekleniyor, Chromium tabanlı tarayıcılar tarafından desteklenmiyor. Bu sorun, Cache-Control: immutable için Chromium desteğini takip etmektedir. Bu soruna yıldız eklemek, bu özellik için destek sağlanmasına yardımcı olabilir.

HTTP önbelleğe alma işleminin daha ayrıntılı bir açıklaması için HTTP Önbelleği ile gereksiz ağ isteklerini önleme bölümüne bakın.

İnce ayar

CDN önbelleklerinin nasıl çalıştığına dair biraz basitleştirilmiş bir açıklama, kaynağı önbelleğe alma ve önbellekten alma anahtarı olarak kaynağın URL'sinin kullanılmasıdır. Pratikte bu durum büyük ölçüde hâlâ geçerlidir, ancak istek üst bilgileri ve sorgu parametreleri gibi öğelerin etkisi nedeniyle biraz karmaşıktır. Sonuç olarak, talep URL'lerini yeniden yazmak hem CHR'yi en üst düzeye çıkarmak hem de kullanıcılara doğru içeriğin sunulmasını sağlamak için önemli bir tekniktir. Doğru şekilde yapılandırılmış CDN örneği, aşırı ayrıntılı önbelleğe alma (CHR'ye zarar verir) ile yeterince ayrıntılı önbelleğe alma (bu durumda kullanıcılara yanlış yanıtların sunulmasına neden olur) arasında doğru dengeyi kurar.

Sorgu parametreleri

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

• Gereksiz sorgu parametreleri

  Varsayılan olarak CDN, aynı temel kaynak olma ihtimali yüksek olsa da 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 giderilir.

• Sorgu parametresi sırası

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

Değiştir

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

Vary üst bilgisi yararlı bir araç olsa da, uygunsuz kullanım CHR'ye zarar verir. Ayrıca, Vary kullanıyorsanız istek başlıklarını normalleştirmek CHR'yi iyileştirmeye yardımcı olur. Örneğin, normalleştirme yapılmaması halinde Accept-Language: en-US ve Accept-Language: en-US,en;q=0.9 istek başlıkları, içerikler aynı olsa bile iki ayrı önbellek girişine neden olur.

kurabiyeler

Çerezler isteklerde Cookie başlığı üzerinden, 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 yere kullanımından kaçınılmalıdır.

Performans özellikleri

Bu bölümde, CDN'ler tarafından temel ürün teklifleri kapsamında yaygın olarak sunulan performans özellikleri ele alınmaktadır. Birçok site bu özellikleri etkinleştirmeyi unutur ve bu nedenle, kolay performans kazançlarını kaybeder.

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 yerine Brotli'yi seçin. Brotli, daha yeni bir sıkıştırma algoritmasıdır ve gzip ile karşılaştırıldığında 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".

Kökenli Brotli

Kaynaktan Brotli, bir CDN'nin, kaynak tarafından Brotli'nin sıkıştırdığı kaynakları sunmasıdır. Bu, tüm CDN'lerin hemen destekleyebilmesi gereken bir özellik gibi görünse de, bir CDN'nin belirli bir URL'ye karşılık gelen kaynağın birden çok sürümünü (diğer bir deyişle, gzip ile sıkıştırılmış ve Brotli tarafından 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 Brotli'nin CDN 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 sunulur (örneğin, Brotli-5). Bu tür bir sıkıştırma, hem önbelleğe alınabilir hem de önbelleğe alınamayan kaynaklar için geçerlidir.

Bu arada, bir kaynak önbelleğe alınabilirse 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şleme kullanır. Bu sıkıştırma 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. Kaynakta Brotli sıkıştırması, önbellekten sunulamayan kaynakların aktarım boyutunu en aza indirir. Sunum isteklerinde gecikmeleri önlemek için kaynak, dinamik kaynakları oldukça kısıtlı 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. Bir 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 kriptografik protokol olan Taşıma Katmanı Güvenliği'nin (TLS) en yeni sürümüdür. TLS 1.3, TLS 1.2'ye kıyasla daha iyi gizlilik ve performans sağlar.

TLS 1.3, TLS el sıkışmasını iki döngüden bire indirger. HTTP/1 veya HTTP/2 kullanan bağlantılar için, TLS el sıkışmasını tek bir gidiş dönüş olacak şekilde kısaltmak, bağlantı kurulum süresini etkili bir şekilde %33 azaltır.

HTTP/2 ve HTTP/3

Hem HTTP/2 hem de HTTP/3, HTTP/1'e kıyasla performans açısından avantajlar sağlar. Bu ikisi arasında, HTTP/3 daha fazla potansiyel performans avantajı sunar. HTTP/3 henüz tam olarak standartlaştırılmamıştır, ancak bu gerçekleştikten sonra büyük ölçüde desteklenecektir.

HTTP/2

CDN'niz varsayılan olarak HTTP/2'yi etkinleştirmediyse etkinleştirmeyi düşünmelisiniz. HTTP/2, HTTP/1'e kıyasla birçok performans avantajı sağlar ve tüm önemli tarayıcılar tarafından desteklenir. HTTP/2'nin performans özellikleri arasında çoklulama, akış önceliği ve üstbilgi sıkıştırma yer alır.

• Multiplex

  Multiplex, muhtemelen HTTP/2'nin en önemli özelliğidir. Multiplex, tek bir TCP bağlantısının aynı anda birden çok istek-yanıt çiftini sunmasını sağlar. Bu, gereksiz bağlantı kurulumlarının 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 sayfanın daha fazla kaynağını isteyebilmesi anlamına da gelir. Multiplex, teorik olarak, birleştirme ve model sayfaları gibi HTTP/1 optimizasyonlarına olan ihtiyacı ortadan kaldırır. Ancak, daha büyük dosyaların daha iyi sıkıştırılmasıyla pratikte bu teknikler geçerliliğini korur.

• Akışta öncelik belirleme

  Multiplex, birden çok eşzamanlı akışa olanak tanır. Akış önceliği ise bu akışların her birinin göreceli önceliğini bildirmek için bir arayüz sağlar. Bu, ilk başta istenmemiş olsa bile sunucunun en önemli kaynakları ilk ö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şılamak (hatta dikkate almak) yükümlülüğü yoktur. Bir site daha fazla CDN aracılığıyla sunulduğunda akış önceliklendirme daha etkili hale gelir.

HTTP/2 kaynak önceliklendirmenin CDN uygulamaları büyük farklılıklar göstermektedir. CDN'nizin HTTP/2 kaynak önceliğini tamamen ve düzgün bir şekilde destekleyip desteklemediğini belirlemek için Is HTTP/2 Fast Yet Yet? (HTTP/2 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ı çevirmek anlamına gelse de, bu değişikliği üretimde etkinleştirmeden önce kapsamlı bir şekilde test etmeniz önemlidir. HTTP/1 ve HTTP/2, istek ve yanıt başlıkları için aynı kuralları kullanır ancak bu kurallara uyulmaması durumunda HTTP/2 çok daha az affedebilir. Sonuç olarak, başlıklara ASCII olmayan veya büyük harfli karakterler ekleme gibi spesifikasyona bağlı olmayan uygulamalar, HTTP/2 etkinleştirildikten sonra hatalara neden olmaya başlayabilir. Bu durumda, tarayıcının kaynağı indirme denemeleri başarısız olur. Başarısız indirme denemesi, Geliştirici Araçları'nın "Ağ" sekmesinde gösterilir. Ayrıca, konsolda "ERR_HTTP2_PROTOCOL_ERROR" hata mesajı görüntülenir.

HTTP/3

HTTP/3, HTTP/2'nin yerini almıştır. Eylül 2020 itibarıyla tüm büyük tarayıcılarda HTTP/3 için deneysel destek mevcuttur ve bazı CDN'ler de bu desteği sağlamaktadır. Performans, HTTP/2'ye göre HTTP/3'ün birincil avantajıdır. Daha açık belirtmek gerekirse, HTTP/3, bağlantı düzeyinde doğrudan engeli ortadan kaldırır ve bağlantı kurulum süresini kısaltır.

• Doğrudan engellemenin ortadan 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 bir çoğullama özelliğini kullanıma sundu. Ancak HTTP/2'de bırakılan tek bir paket, bir bağlantıdaki tüm akışları engeller (satır başı engelleme olarak bilinen bir olay). HTTP/3'te bırakılan paket yalnızca tek bir akışı engeller. Bu iyileşme büyük ölçüde, HTTP/3'ün TCP yerine UDP (HTTP/3, QUIC üzerinden UDP'yi kullanır) kullanması sonucu meydana gelmektedir. Bu, HTTP/3'ü özellikle sıkışık veya kayıplı ağlar üzerinden veri aktarımı için kullanışlı hale getirir.

• Kısaltılmış bağlantı kurulum 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ş dönüş gerekir ve mevcut bir bağlantıyı devam ettirmek için gidiş geliş gerekmez.

Kötü ağ bağlantılarında kullanıcılar üzerinde en büyük etkiyi HTTP/3'ün etkisi olacak: HTTP/3'ün paket kaybını öncekilerden daha iyi işlemesinin yanı sıra 0-RTT veya 1-RTT bağlantı kurulumundan kaynaklanan mutlak zaman tasarrufu, yüksek gecikmeli ağlarda daha fazla olacak.

Resim optimizasyonu

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

Küçültme

Küçültme, gereksiz karakterleri JavaScript, CSS ve HTML'den kaldırır. Küçültme işleminin CDN yerine kaynak sunucuda yapılması tercih edilir. Site sahipleri, küçültülecek kod hakkında daha fazla bilgiye sahiptir ve bu nedenle genellikle CDN'ler tarafından kullanılanlardan daha agresif azaltma teknikleri kullanabilirler. Bununla birlikte, kaynakta kodu küçültmek mümkün değilse CDN tarafından küçültmek iyi bir alternatiftir.

Sonuç

• CDN kullanma: CDN'ler kaynakları hızlı bir şekilde yayınlar, kaynak sunucudaki yükü azaltır ve trafik artışlarının yönetilmesine 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üreler için de olsa önbelleğe alınabilir ve eklenmelidir. İç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.