Yerel dosyalar ve CDN karşılaştırması


15

Bir web sitesi yükleme süresi bir endişe kaynağıysa, bir JavaScript veya CSS dosyasına başvururken genellikle daha iyi olur? CDN kullanmak daha iyi olur mu yoksa bu sadece daha fazla HTTP isteği ekler mi?

Yanıtlar:


12

CDN, tüm statik dosyalar (.css / .js / images) için kullanılmalıdır.

Bununla birlikte, javascript veya css dosyaları benzersiz bir kullanıcı dizesi veya bu tür bir şey içerecek şekilde dinamik bir özelliğe sahip olabilir. Bu durumda, CDN sunucusunun amacı bozacak her istek üzerine kaynak sunucuyla iletişim kurması gerekir.

CSS ve Javascript'iniz tüm kullanıcılar için statikse, bir CDN kullanmak doğru yoldur. Bu, ekstra HTTP isteklerine neden olmaz çünkü css ve js dosyalarını yalnızca kendi web sunucunuz yerine CDN'den yükler (satır içi kod kullanmıyorsanız). Bu nedenle, bu istekleri sunucunuzdan yükleyen bir kullanıcı tarayıcısı yerine CDN aracılığıyla yüklenecek, yalnızca bu isteklerin nereye gönderileceğini değiştirdiğiniz başka bir istek yoktur (yine şu anda satır içi kod kullanmadığınız sürece).

Bir CDN kullanmanın diğer faydaları, CDN sunucusunun büyük olasılıkla son kullanıcılarınıza daha yakın bir konumda bulunması ve başlangıç ​​noktanızın yükleme sürelerine fayda sağlamasıdır. CDN sunucuları ayrıca, web sunucusunu statik içerik için özel olarak hazırlayarak, statik içeriği başlangıç ​​sunucunuzdan çok daha hızlı sunacak şekilde ayarlanmıştır.


2
CDN daha yakın değilse ve edns-client-subnet kullanmıyorsa, performansı hiç artırmayacaktır. Bu bir "diğer yarar" değildir, istemciye yakın olmak, muhtemelen bazı DOS koruma / içerik optimizasyonu (bunlardan bahsetmemenize rağmen) sağlamak tek faydaları vardır.
symcbean

Bir CDN kullanmanın en büyük yararı, büyük olasılıkla kullanıcının aynı CDN'yi kullanan bir web sitesini önceden ziyaret etmiş olması ve tarayıcının onu önbelleğe almasıdır, bu nedenle kullanıcı web sitenize geldiğinde tarayıcı herhangi bir istek göndermez.
Offir Pe'er

3

Bir Kullanarak barındırma geleneksel web vs CDN örneğin CSS, JS olarak statik dosya dağıtım ve resimler yaygın tercih edilir. Bunun nedeni, dosyalarınız CDN'nin uç sunucularında önbelleğe alındıktan sonra, site ziyaretçilerinize kaynak sunucu yerine en yakın varlık noktasından (PoP) statik içerik dağıtılmasıdır.

Çoğu durumda, bu, istemci ve sunucu arasındaki mesafeyi kısaltır ve böylece ek HTTP istekleri eklemeden yükleme sürelerinin iyileştirilmesine yardımcı olur. Bu ayrıca yedekliliği artırmak, menşei yükü kaldırmak vb. Gibi diğer alanlarda da yardımcı olur.


2

Bir CDN'ye ihtiyacınız varsa bir CDN kullanın. Kullanıcınız globalse ve geniş bir alana yayılmışsa veya kendi sunucunuzda depolamak istemediğiniz çok fazla içeriğe sahipseniz, o zaman bir CDN yararlıdır. Genel olarak, sunucu kullanıcıya daha yakınsa içeriğinize erişimi hızlandırabilir. Çok sayıda GB veya Terabayt statik veri ve bu içeriğe erişmek için ağır bir yükünüz varsa, bir CDN buna yardımcı olabilir.

Bununla birlikte, küçük, yerel siteler veya hafif yüklü siteler nadiren bu tür şeylere ihtiyaç duyar ve bir CDN, önbelleğe alma sorunları gibi kurulumunuza, çalışmanıza ve iş akışınıza yalnızca bir tane daha komplikasyon ekleyebilir.

Çoğu zaman insanların bir CDN kullandıklarını görüyorum çünkü okudukları bir başka sebep yok.


İşaret ettiğiniz için teşekkürler her zaman gerekli değildir ve gerçekten de gereksiz komplikasyonlar ekler. Benim durumumda bir arka uç varlık birleştirici ve önbellek minifed dosyaları ile bir laravel tabanlı cms kullanıyorum S3 cdn, gulp ve vc birkaç js dosyaları üzerinde zaman kaybı oldu. Ben DB önbellekleme ve hız için uygun kod odaklanmak istiyorum
Raja Khoury

1

Bir CDN kullanmak, nasıl uygulandığına bağlı olarak bir web sitesine hem bir yük hem de bir fayda olabilir.

Olumlu Noktalar

  1. Son kullanıcıya daha yakın saklanan statik içerik (daha hızlı yükleme süreleri)
  2. Ek alt alan adları ( cdn1.example.com, cdn2.example.comvb.), Bu, tarayıcılardaki dosya indirmelerini, herhangi bir anda aynı tam nitelikli alan adından iki eşzamanlı dosyayla sınırladıkları doğal sınırdır. Diğer bir deyişle, bu örneği kullanarak , bir CDN hizmetine ve kaynağa erişen üç CDN etki alanının hepsinden 2 dosya , 2 dosya ve 2 dosya www.example.comindirirken HTML'ye erişirsiniz .cdn1.example.comcdn2.example.comcdn3.example.com

"Alan adı başına 2 eşzamanlı dosya" nın nereden geldiğini belirtebilir misiniz? Kesinlikle tarayıcı başına. Ayrıca HTTP / 2'nin ortaya çıkmasıyla, Domain kırma bir tartışma konusu haline geldi.
Patrick Mevzek

0

Bir CDN'de barındırmanın birçok dezavantajı vardır:

  1. Gizlilik. Bir CDN'de komut dosyaları / stil sayfaları / yazı tipleri barındıran bir siteye her gittiğinizde, CDN siteyi ziyaret ettiğinizi bilir.
  2. Çevrimdışı zaman. Son haftalarda cloudflare vb., Yükleme sürelerinin birkaç dakika boyunca çok yavaş veya hatta çevrimdışı olduğu birkaç saat vardı. En iyi durumda, siteniz çirkin görünüyor, bu gerçekleştiğinde, en kötüsü, rakiplerinizin de sorun yaşadığı bir zamanda tamamen kullanılamaz ve siteniz çevrimiçi olsaydı ve onların değilse, müşterilerinizi alabilirsiniz.
  3. Güvenlik. CDN tehlikeye girebilir (daha önce olmuştu). En iyi durumda sunucunuz kötü amaçlı yazılım yayıyorsa, en kötü durumda verileriniz artık herkese açık veya yok olmuştur.

Avantajların önemsiz olmasına kıyasla:

  1. Yüklenecek daha az veri: site başına yaklaşık 100 kb'lık komut dosyaları hakkında konuşuyoruz. Düşük kalitedeki 1 resim bundan daha fazlasını oluşturur. Dakikada 5.000.000 ziyaret gibi sınırlarında bir web siteniz yoksa, bir fark yaratmaz. Ve eğer, yük dengeleyici ve daha fazla web sunucusu ile muhtemelen daha iyi bir sunucu ortamı kurmalısınız, çünkü CDN'leri kullanmak sorunlarınızı çözmeyecektir.
  2. Daha hızlı yükleme süreleri, CDN sunucuları istemciye daha yakın olduğu için: AB'den ABD'ye gecikmenin neredeyse tüm bağlantılar için yaklaşık 100ms olduğu zamanlarda, css 50ms veya 100ms olarak yüklenir.

Üretim ortamında CDN kullanmanın sıfır nedeni gibi.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.