Neden stilleri / komut dosyalarını HTML’e bağlamak yerine gömmeyin?

Performansı artıran HTTP isteklerinin sayısını azaltmak için CSS ve JavaScript dosyalarını birleştirdik. Sonuç şöyle HTML'dir:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Bunları bizim için yapmak için sunucu tarafında / derleme mantığımız varsa, neden bir adım daha ileri götürüp bu birleştirilmiş stilleri ve komut dosyalarını HTML'ye gömmeyin?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Bu iki daha az HTTP isteği, ancak bu tekniği pratikte görmedim. Neden olmasın?

Çünkü HTTP isteklerini kaydetmek, önbelleğe almayı başararak çok az işe yarar. Stil sayfaları ve komut dosyaları ayrı ayrı sunulursa, çok iyi önbelleğe alınabilir ve çılgınca farklı sayfalara yapılan birçok istek için itfa edilebilir. Aynı HTML sayfasında ezilirlerse, her biriyle yeniden iletilmeleri gerekir. Tek. İstek.

Bu sayfanın HTML, örneğin şu anda 13 KB. 180 KB’lık CSS önbelleğe çarptı ve 360 ​​KB’lik JS’de de oldu. Her iki önbellek vuruşunda eksi bir süre geçmiştir ve neredeyse hiç bant genişliği tüketilmemiştir. Tarayıcınızın ağ profilini çırpın ve başka sitelerde deneyin.

Çünkü Web performansı gerçekten önemli! % 99 kez size daha hızlı son kullanıcı tepki süreleri verecektir.

İşte Velocity Conf.

• Bing - 2 saniye daha yavaş bir sayfa gelir / kullanıcı% 4,3 düşüşle sonuçlandı.
• Google - 400 milisaniyelik bir gecikme, aramalarda / kullanıcılarda% 0.59 düşüşe neden oldu.
• Yahoo ! - 400 milisaniyelik bir yavaşlama, tam sayfa trafiğinde% 5-9'luk bir düşüşe neden oldu.
• Shopzilla - Sitelerini 5 saniyeye kadar hızlandırmak dönüşüm oranını% 7-12 artırdı, arama motoru pazarlamasından gelen oturum sayısını iki katına çıkardı ve gerekli sunucu sayısını yarıya indirdi.
• Mozilla - Açılış sayfalarındaki 2,2 saniye tıraş, indirme dönüşümlerini% 15,4 oranında artırdı; bu da yılda 60 milyon daha fazla Firefox indirme işlemine neden olacağını tahmin ediyor.
• Netflix - Tek bir optimizasyon benimseme, gzip sıkıştırma,% 13-25'lik bir hızlanma ile sonuçlandı ve giden ağ trafiğini% 50 oranında azalttı.

Web Performansı Optimizasyonunda öncü olan Steve Souders’tan,

Son kullanıcı yanıt süresinin% 80-90'ı ön uçta harcanıyor - Önce buradan başlayın.

Harici dosyaların kullanılması, JavaScript ve CSS dosyalarının tarayıcı / ağlar / proxy sunucular tarafından önbellekte saklanması nedeniyle daha hızlı sayfalar üretir (Önbellek başlıklı HTTP protokolünde tanımlandığı gibi). HTML belgelerinde satır içi olan JavaScript ve CSS, her HTML belgesi istendiğinde indirilir. Bu, gereken HTTP isteklerinin sayısını azaltır, ancak HTML belgesinin boyutunu artırır. Jquery benzeri komut dosyaları kullanıyorsanız, 300 KB'lik komut dosyalarını yeniden kullanmak kolaydır ve web sitenizde tek bir uygulamayı çalıştıran tek bir uygulamayı çalıştıran herkesin düşük gecikmeli 100 MBits / s bant genişliğine sahip olduğuna inanmayın. % 99 kez size daha hızlı son kullanıcı tepki süreleri verecektir.

İstenen HTML belgelerinin sayısına göre harici JavaScript ve CSS bileşenlerinin önbelleğe alınma sıklığı da önemlidir. Sitenizdeki kullanıcılar oturum başına birden çok sayfa görünümüne sahipse ve sayfalarınızın çoğu aynı komut dosyalarını ve stil sayfalarını (paketler) yeniden kullanıyorsa, önbelleğe alınmış harici dosyalardan daha büyük bir potansiyel fayda vardır.

Ancak, tek sayfa uygulamalarında veya oturum başına tek sayfa görünümünde olan web sitelerinde satırlar-bazen de tercih edilir. Altın bir kural yoktur ve genellikle son kullanıcı performansının gerçekten dahil olduğu çok özel web sitelerini ilgilendirdiği için genellikle unutun.

Sen okuyabilir burada niçin performans hususlar (Yasal Uyarı: yazarıyım)

HTTP’nin en son sürümü 1999’da yeniden oluşturuldu. 1999’da herkes internete çevirmeli ağ ile bağlandı. İnternet çok yavaştı. 16 yıl sonra, işler büyük ölçüde değişti, ancak kullandığımız protokoller değişmedi.

'Önbelleğe almayı engellediği için' satır içi yapmamamız gereken cevaplar, özellikle süper hızlı internet döneminde biraz yanıltıcıdır. Hesaplamaları gerçekten yaptığınızda, satır içi işlem yapmışsanız önbellek ılık ve önbellek soğuk kullanıcılarla yükleme süreleri arasında genellikle önemsiz bir fark vardır. Orada aslında olan küçük bir fark inlined çünkü doğal olarak değil, çünkü HTTP / 1.1 esnek olmayan tasarımın.

SPDY protokolü, sunucu push adı verilen bir şey uygular . Bu, temel olarak HTML belgesinin kendisinin ve protokolün içini çizer. Akıllı bir sunucu, müşterinin zaten hangi kaynaklara sahip olduğunu bilir. Aptal bir sunucu ne olursa olsun her şeyi gönderir - bu yine de bir performans avantajı olur, ancak bant genişliği açısından maliyeti olabilir. Tarayıcı içeriğinde önbellek içeriyorsa, gelen kopyaları kolayca atabilir. Sunucu, ek kaynakları göndermeden önce HTML yüklenene kadar bekler - teoride tarayıcı, sunucuyu zorla iptal etmek için bir sinyal gönderebilir.

HTTP / 2.0, SPDY'ye dayanır ve büyük olasılıkla sunucu zorlaması uygular, ancak teoride bugün SPDY'yi kullanmaya başlayabilirsiniz. Dolayısıyla, satır içi yapmamamızın asıl nedeni eskilerden biri - şu anda var olan protokoller eski ve 'protokol düzeyinde satır içi' elde etmek için yeterince esnek değiller.

Önbellekleme ve geri alma, diğer cevapların ortaya çıkardığı endişelere ek olarak, başka, daha belirsiz bir sorunu vurgulamak isterim: ayrıştırma .

HTML’de görünen JavaScript, aşağıdaki örnekte olduğu gibi ayrıştırma sorunlarıyla karşılaşabilir:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... bu, HTML’yi tetikleyen bazı karakterlerden kaçmak için komut dosyanızı dönüştürmeniz gerektiği anlamına gelir. CSS ve JavaScript'i harici kaynaklar olarak tedarik ettiğinizde bu sorun ortadan kalkar, çünkü artık 'ebeveyn' ayrıştırma bağlamını hesaba katmak zorunda kalmazlar.

İçeriğinizi XML olarak sunarsanız, CDATA bölümlerini kullanarak bunun bir parçası olabilirsiniz. Bununla birlikte, CDATA benzer bir sorunla geliyor:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Inliners dikkat et.

İçeriğin sunumunun stilinden ayrılması genellikle daha az http isteğinden daha büyük bir avantajdır.

Tüm stilleri ayırmak, yeniden kullanımı ve paylaşılan dosyaları etkinleştirir ve teşvik eder.

Dosyaların içeriği de hem statik hem de hem sunucu hem de istemcileri hem o sayfa hem de ziyaret edilen diğer sayfalar için önbelleğe almak için hazır olacaktır.

Gerçi size özel bir soru için ... Sunucunun minyatürleştirmeyi kendisi yapması durumunda, varlıkları korumak ve hata ayıklamak zorlaşır. Ancak birçok çerçeve bunu şimdi dosya düzeyinde yapar, örneğin tüm cs ve tüm js. Örneğin, raylar çerçevesindeki yakut şimdi üretim için varlıklarını küçültüyor. 5-10 ekstra http istekleri genellikle tıkanıklık değildir, 100'den fazla http istekleri varsa (genellikle resimlerle karşılaşırsınız).

Gerçekte sayfalara kodu eklemenin ek adımı, indirme sırasını dikkatli bir şekilde yönetmek zorunda kalacağınız büyük sayfaların dezavantajına sahip olacak ve sayfanın geri kalanı (şimdi büyük) sayfasının geri kalan kısmı olmadan sık sık görüntüleyememesi olacaktır. İndiriliyor

1. Çift kodlamayı en aza indirin. Zaman kazanmak için (Bir sayfa için kodlanmış stil ve JS işlevini yeniden kullanabilirsiniz).
2. Değişim çabasını en aza indirin. (Müşteriniz sizden web sitesinin düğme rengini değiştirmenizi isterse. Bir sayfaya bir gitmeniz gerekir).
3. Yükleme süresini azaltın (CSS'niz ve JS'niz yineleniyorsa, tek tek sayfaların boyutunun artması ve indirilmesi zaman alan anlamına gelir.
4. Uzaktan kullanım. (ortak CSS js JS'nizi uzaktaki bir yere koyabilirsiniz.
5. Hata onarım süresini kısaltın. Bir işlevde bir hata varsa, gömülü JS ve CSS'deki hataları düzeltmek için sayfa sayfa gitmeniz gerekir.
6. SEO’yu artırmak için (içeriği yalnızca meta verilerle ayırın)
7. Daha temiz ve anlaşılır bir kod (Hepsini bir dosyaya gömerseniz hata ayıklama ve kodların açıklığı ortadan kalktı. Her sayfa çok uzun bir sayfa olacak).
8. Ek olarak, bu ürünün boyutunu azaltmanıza yardımcı olacaktır.
9. Ancak yine de, en benzersiz şeyi aynı sayfaya gömmeyi düşünebilirsiniz.

Stilleri / komut dosyalarını HTML'ye gömmemeliyiz çünkü

Her sayfa isteğinde gömülü stiller / komut dosyaları indirilmelidir:

Bu stiller tarayıcı tarafından önbelleğe alınamaz ve başka bir sayfa için yeniden kullanılamaz. Bu nedenle, olabildiğince az miktarda CSS / JS yerleştirmeniz önerilir.

bunun yerine css / scriptleri bağlamak için linkler kullandığımız zaman linking coz kullanıyoruz.

Birden fazla sayfa isteği için site hızı artar:

Bir kişi web sitenizi ilk ziyaret ettiğinde, tarayıcısı geçerli sayfanın HTML'sini ve bağlantılı CSS ve JS dosyasını indirir. Başka bir sayfaya gittiklerinde, tarayıcılarının yalnızca yeni sayfanın HTML'sini indirmesi gerekir, CSS / JS dosyası önbelleğe alınır, bu nedenle tekrar indirilmesi gerekmez. Bu, özellikle büyük bir stil ve komut dosyanız varsa, büyük bir fark yaratabilir.