ทำไมไม่ฝังสไตล์ / สคริปต์ใน HTML แทนที่จะเชื่อมโยง?

เราเชื่อมไฟล์ CSS และ JavaScript เข้าด้วยกันเพื่อลดจำนวนคำขอ HTTP ซึ่งช่วยเพิ่มประสิทธิภาพ ผลที่ได้คือ HTML ดังนี้

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

หากเรามีตรรกะฝั่งเซิร์ฟเวอร์ / บิลด์เพื่อทำสิ่งนี้ให้กับเราทำไมไม่ลองอีกขั้นหนึ่งแล้วฝังสไตล์และสคริปต์ที่ต่อกันเหล่านั้นลงใน HTML

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

นั่นเป็นคำขอ HTTP ที่น้อยลงสองคำขอ แต่ฉันไม่เคยเห็นเทคนิคนี้มาก่อน ทำไมจะไม่ล่ะ?

เนื่องจากการบันทึกคำขอ HTTP นั้นมีการใช้งานเพียงเล็กน้อยเมื่อคุณทำสำเร็จโดยแบ่งแคช หากสไตล์ชีตและสคริปต์ให้บริการแยกจากกันพวกเขาสามารถแคชได้เป็นอย่างดีและตัดจำหน่ายตามคำขอจำนวนมากไปยังหน้าเว็บที่แตกต่างกันจำนวนมาก หากพวกเขาถูกกรีดในหน้า HTML เดียวกันพวกเขาจะต้องถูกส่งซ้ำกับทุก เดียว ขอร้อง

ตัวอย่าง HTML ของหน้านี้คือ 13 KB ในขณะนี้ CSS ขนาด 180 KB เข้าถึงแคชและดังนั้นจึงมีขนาด 360 KB ของ JS การแคชทั้งสองครั้งใช้เวลาน้อยและใช้แบนด์วิธไม่มากนัก ชักโปรไฟล์เครือข่ายของเบราว์เซอร์ของคุณและลองใช้กับเว็บไซต์อื่น ๆ

เพียงเพราะประสิทธิภาพของเว็บมีความสำคัญจริงๆ! 99% เท่ามันจะช่วยให้คุณตอบสนองผู้ใช้ปลายทางได้เร็วขึ้น

นี่คือตัวอย่างเล็ก ๆ น้อย ๆ จาก Velocity Conf

• Bing - หน้าเว็บที่ช้าลง 2 วินาทีส่งผลให้รายได้ / ผู้ใช้ลดลง 4.3%
• Google - ความล่าช้า 400 มิลลิวินาทีทำให้การค้นหา / ผู้ใช้ลดลง 0.59%
• ยาฮู ! - การชะลอตัว 400 มิลลิวินาทีทำให้การเข้าชมแบบเต็มหน้าลดลง 5-9%
• Shopzilla - เพิ่มความเร็วเว็บไซต์ของพวกเขา 5 วินาทีเพิ่มอัตราการแปลง 7-12% เพิ่มจำนวนเซสชันจากการตลาดเสิร์ชเอนจินเป็นสองเท่าและลดจำนวนเซิร์ฟเวอร์ที่ต้องการลงครึ่งหนึ่ง
• Mozilla - การโกนหน้า Landing Page 2.2 วินาทีเพิ่มการแปลงการดาวน์โหลด 15.4% ซึ่งคาดว่าจะมีการดาวน์โหลด Firefox มากกว่า 60 ล้านครั้งต่อปี
• Netflix - การใช้การปรับให้เหมาะสมแบบเดี่ยว, การบีบอัด gzip, ทำให้ความเร็วเพิ่มขึ้น 13-25% และลดทราฟฟิกเครือข่ายขาออกลง 50%

จาก Steve Souders ผู้บุกเบิกการเพิ่มประสิทธิภาพเว็บไซต์

80-90% ของเวลาตอบสนองผู้ใช้จะใช้กับส่วนหน้า - เริ่มที่นี่ก่อน

การใช้ไฟล์ภายนอกสร้างหน้าได้เร็วขึ้นเนื่องจากไฟล์ JavaScript และไฟล์ CSS ถูกแคชไว้โดยเบราว์เซอร์ / เครือข่าย / พร็อกซี่ (ตามที่กำหนดไว้ในโปรโตคอล HTTP พร้อมกับส่วนหัวของแคช) JavaScript และ CSS ที่อยู่ในเอกสาร HTML จะถูกดาวน์โหลดทุกครั้งที่มีการร้องขอเอกสาร HTML สิ่งนี้จะลดจำนวนคำขอ HTTP ที่จำเป็น แต่เพิ่มขนาดของเอกสาร HTML หากคุณใช้สคริปต์ที่เหมือน Jquery มันง่ายต่อการรีเฟรชสคริปต์ 300 KB และไม่เชื่อว่าทุกคนมีแบนด์วิดท์ 100 MBits / s ที่มีเวลาแฝงต่ำเรียกใช้แอปพลิเคชันเดียว - เบราว์เซอร์ที่เปิดบนเว็บไซต์ของคุณ 99% เท่ามันจะช่วยให้คุณตอบสนองผู้ใช้ปลายทางได้เร็วขึ้น

ความถี่ที่คอมโพเนนต์แคช JavaScript และ CSS ภายนอกสัมพันธ์กับจำนวนเอกสาร HTML ที่ร้องขอก็มีความสำคัญเช่นกัน หากผู้ใช้บนไซต์ของคุณมีการดูหน้าเว็บหลายครั้งต่อเซสชันและหน้าเว็บหลายหน้าของคุณใช้สคริปต์และสไตล์ชีตเดียวกัน (ชุดข้อมูล) เดียวกันจะมีประโยชน์มากขึ้นจากไฟล์ภายนอกที่เก็บไว้ในแคช

แต่อินไลน์คือ - บางครั้ง - ดีกว่าสำหรับแอปพลิเคชันหน้าเดียวหรือเว็บไซต์ที่มีการดูหน้าเดียวต่อเซสชัน ไม่มีกฎทองและโดยทั่วไปจะลืมมันเพราะมันเกี่ยวข้องกับเว็บไซต์ที่เฉพาะเจาะจงมากโดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับประสิทธิภาพของผู้ใช้ปลายทาง

คุณสามารถอ่านได้ที่นี่ทำไมเรื่องประสิทธิภาพ (ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้เขียน)

HTTP เวอร์ชันล่าสุดสร้างขึ้นเมื่อปี 2542 ในปี 1999 ทุกคนเชื่อมต่อกับอินเทอร์เน็ตด้วยการหมุนโทรศัพท์ อินเทอร์เน็ตช้ามาก 16 ปีต่อมาสิ่งต่าง ๆ ได้เปลี่ยนแปลงไปอย่างมาก แต่โปรโตคอลที่เราใช้นั้นไม่มี

คำตอบที่เราไม่ควรทำแบบอินไลน์ 'เพราะมันรบกวนการใช้แคช' ​​เป็นการหลอกลวงเล็กน้อยโดยเฉพาะในยุคของอินเทอร์เน็ตที่เร็วมาก เมื่อคุณทำการคำนวณจริงมักจะมีความแตกต่างเล็กน้อยระหว่างเวลาโหลดกับผู้ใช้แคชอุ่นและแคชเย็นถ้าคุณมีการ inline ข้อเท็จจริงที่ว่ามีคือความแตกต่างเล็ก ๆ ไม่ได้โดยเนื้อแท้เพราะคุณได้ inlined แต่เพราะการออกแบบที่ยืดหยุ่นของ HTTP / 1.1

โปรโตคอล SPDY ใช้สิ่งที่เรียกว่าเซิร์ฟเวอร์พุช การทำเช่นนี้สำคัญที่จะนำเอาเอกสาร HTML ออกมาและเข้าสู่โปรโตคอล เซิร์ฟเวอร์อัจฉริยะจะรู้ว่าทรัพยากรที่ลูกค้ามีอยู่แล้ว เซิร์ฟเวอร์โง่จะส่งทุกอย่างโดยไม่คำนึงว่าจะเป็นประโยชน์ต่อประสิทธิภาพ แต่อาจมีค่าใช้จ่ายในเรื่องของแบนด์วิดท์ หากเบราว์เซอร์มีเนื้อหาในแคชเบราว์เซอร์ก็สามารถทิ้งสำเนาที่เข้ามาได้ เซิร์ฟเวอร์รอจนกระทั่งโหลด HTML ก่อนที่จะส่งทรัพยากรเพิ่มเติมตามทฤษฎีแล้วเบราว์เซอร์สามารถส่งสัญญาณเพื่อยกเลิกการพุชเซิร์ฟเวอร์

HTTP / 2.0 ขึ้นอยู่กับ SPDY และเป็นไปได้มากที่สุดที่จะใช้เซิร์ฟเวอร์แบบพุช แต่ในทางทฤษฎีแล้วคุณสามารถเริ่มใช้ SPDY ได้ในวันนี้ ดังนั้นเหตุผลที่แท้จริงที่เราไม่อินไลน์คือหนึ่งในมรดก - โปรโตคอลที่มีอยู่ในปัจจุบันนั้นเก่าและไม่ยืดหยุ่นพอที่จะบรรลุ 'อินไลน์ซับเน็ตระดับโปรโตคอล'

นอกจากนี้ยังมีการแคชและความกังวลเรียกว่าคำตอบอื่น ๆ ยกผมอยากจะเน้นอีกปัญหาที่คลุมเครือมากขึ้น: การแยก

JavaScript ที่ปรากฏใน HTML สามารถพบปัญหาในการวิเคราะห์คำได้เช่นในตัวอย่างนี้:

<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>

... ซึ่งหมายความว่าคุณจะต้องแปลงสคริปต์ของคุณเพื่อหลีกเลี่ยงอักขระบางตัวที่เรียกใช้ใน HTML ปัญหานี้จะหายไปเมื่อคุณจัดหา CSS และ JavaScript เป็นทรัพยากรภายนอกเพราะพวกเขาไม่จำเป็นต้องใช้บริบทการแยกวิเคราะห์ผู้ปกครอง

หากคุณให้บริการเนื้อหาของคุณเป็น XML คุณจะมีส่วนร่วมในเรื่องนี้โดยใช้ส่วน CDATA อย่างไรก็ตาม CDATA มาพร้อมกับปัญหาที่คล้ายกัน:

<?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

การแยกเนื้อหาจากการกำหนดสไตล์ของงานนำเสนอมักจะเป็นข้อได้เปรียบที่ใหญ่กว่าคำขอ HTTP ที่น้อยลง

การแยกการจัดแต่งทรงผมออกทั้งหมดช่วยให้สามารถใช้ซ้ำและแชร์ไฟล์ได้

เนื้อหาของไฟล์จะคงที่และพร้อมใช้งานสำหรับการแคชบนเซิร์ฟเวอร์และไคลเอนต์สำหรับทั้งหน้านั้นและหน้าอื่น ๆ ที่มีการเยี่ยมชม

สำหรับคุณโดยเฉพาะคำถามว่า ... หากเซิร์ฟเวอร์ทำการ minification นั้นจะทำให้สินทรัพย์ยากต่อการดูแลและแก้ไขปัญหา อย่างไรก็ตามเฟรมเวิร์กจำนวนมากทำได้ในระดับไฟล์เช่นทุก cs และ js ทั้งหมด ตัวอย่างเช่นตอนนี้กรอบทับทิมบนรางลดขนาดสินทรัพย์เพื่อการผลิต คำขอ HTTP เพิ่มเติม 5-10 ครั้งมักไม่ใช่ปัญหาคอขวด แต่จะมีมากกว่าหากมีคำขอ HTTP มากกว่า 100 รายการ (ซึ่งคุณมักจะได้รับพร้อมรูปภาพ)

ขั้นตอนพิเศษของการรวมรหัสในหน้าเว็บนั้นจะมีข้อเสียของหน้าเว็บที่ใหญ่กว่าซึ่งคุณจะต้องจัดการลำดับการดาวน์โหลดอย่างระมัดระวังและหน้าไม่สามารถแสดงเนื้อหาได้บ่อยครั้งโดยไม่ต้องใช้หน้าอื่น ๆ กำลังดาวน์โหลด

1. ลดการเข้ารหัสซ้ำซ้อน เพื่อประหยัดเวลา (คุณสามารถใช้สไตล์และฟังก์ชั่น JS ที่เข้ารหัสสำหรับหนึ่งหน้า)
2. ลดความพยายามในการเปลี่ยนแปลงให้น้อยที่สุด (หากลูกค้าขอให้คุณเปลี่ยนสีปุ่มของเว็บไซต์คุณต้องไปทีละหน้า)
3. ลดความเร็วในการโหลด (หาก CSS และ JS ของคุณซ้ำกันหมายถึงการเพิ่มขนาดหน้าแต่ละหน้าและใช้เวลานานในการดาวน์โหลด แต่ CSS CSS ทั่วไปไม่จำเป็นต้องดาวน์โหลดซ้ำแล้วซ้ำอีก)
4. การใช้งานระยะไกล (คุณสามารถวาง CSS ทั่วไป js JS ของคุณในสถานที่ห่างไกลไม่ใช่เซิร์ฟเวอร์โฮสต์เดียวกัน)
5. ลดเวลาแก้ไขบั๊ก หากมีข้อผิดพลาดในฟังก์ชั่นเดียวคุณต้องไปทีละหน้าเพื่อแก้ไขข้อบกพร่องใน JS และ CSS แบบฝัง
6. วิธีเพิ่ม SEO (แยกเนื้อหาด้วยข้อมูลเมตา)
7. ทำความสะอาดและเข้าใจรหัส (หากคุณฝังทั้งหมดในหนึ่งไฟล์ debug และความคมชัดของรหัสหายไปและแต่ละหน้าจะเป็นหน้ายาวมาก)
8. นอกจากนี้จะช่วยให้คุณลดขนาดของผลิตภัณฑ์
9. แต่คุณก็ยังสามารถฝังสิ่งที่แปลกที่สุดไว้ในหน้าเดียวกันได้

เราไม่ควรฝังสไตล์ / สคริปต์ใน HTML เพราะ

ต้องดาวน์โหลดสไตล์ / scrips ในตัวพร้อมกับคำขอหน้าเว็บทุกหน้า:

เบราว์เซอร์ไม่สามารถแคชสไตล์เหล่านี้และนำไปใช้กับหน้าอื่นได้อีก ด้วยเหตุนี้จึงแนะนำให้ฝัง CSS / JS จำนวนน้อยที่สุดเท่าที่จะทำได้

เราใช้การเชื่อมโยงแทนเมื่อเราใช้การเชื่อมโยงเพื่อผูก css / สคริปต์

ความเร็วไซต์เพิ่มขึ้นสำหรับการร้องขอหลายหน้า:

เมื่อบุคคลเข้าชมเว็บไซต์ของคุณเป็นครั้งแรกเบราว์เซอร์จะดาวน์โหลด HTML ของหน้าปัจจุบันรวมถึงไฟล์ CSS และ JS ที่เชื่อมโยง เมื่อพวกเขานำทางไปยังหน้าอื่น ๆ เบราว์เซอร์ของพวกเขาจะต้องดาวน์โหลด HTML ของหน้าใหม่เท่านั้นไฟล์ CSS / JS ถูกแคชดังนั้นจึงไม่จำเป็นต้องดาวน์โหลดอีกครั้ง สิ่งนี้สามารถสร้างความแตกต่างใหญ่โดยเฉพาะอย่างยิ่งถ้าคุณมีสไตล์และไฟล์สคริปต์ขนาดใหญ่