เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
อิมเมจ Base64 แบบอินไลน์ใน CSS: เมื่อข้อมูล: URI ช่วยเหลือและเมื่อเสียหาย
· เหตุใดจึงสำคัญ
base64 ผลงาน
การฝังรูปภาพเป็นข้อมูล Base64: URI ลบคำขอออก แต่ขยายไฟล์และเอาชนะการแคช โพสต์นี้อธิบายว่าเมื่อใดที่การแลกเปลี่ยนจะคุ้มค่า และเมื่อใดที่ไฟล์แยกจะเร็วกว่า
สไตล์ชีตที่ขยายเป็นหลายร้อยกิโลไบต์ - นิสัยที่ฝังอยู่ในทีมหนึ่งและลักษณะที่ปรากฏในการกำหนดเวลาโหลด
ทีมพัฒนาตัดสินใจว่าการแทรกไอคอนขนาดเล็กเป็นข้อมูล Base64: URI ใน CSS จะลดคำขอ HTTP และปรับปรุงความเร็วในการโหลดหน้าเว็บ เมื่อเวลาผ่านไป เมื่อมีการเพิ่มไอคอนมากขึ้น สไตล์ชีตก็เพิ่มขึ้นเป็น 400 กิโลไบต์
บันเดิล CSS ซึ่งควรมีกฎสไตล์ ถูกครอบงำโดยข้อมูลรูปภาพแล้ว ทีมงานวัดเวลาในการโหลดและพบว่าหน้าเว็บช้ากว่าก่อนอินไลน์ ไม่ใช่เร็วขึ้น ปัญหาเริ่มชัดเจน: สไตล์ชีต 400-กิโลไบต์จะถูกดาวน์โหลดทุกครั้งที่โหลดหน้าและแคชต่อหน้า ในขณะที่หากไอคอนเป็นไฟล์แยกกัน ไฟล์ไอคอนเดียวจะถูกแคชและแบ่งปันในทุกหน้า
ข้อมูลอะไร: URI แบบอินไลน์และเหตุใดจึงเป็น Base64 — ไวยากรณ์ ประเภทสื่อ และการปรับขนาด
การเพิ่มหน้าลงในไซต์ทำให้ปัญหาแย่ลง เนื่องจากแต่ละหน้าจะดาวน์โหลดสไตล์ชีตเดียวกันพร้อมรูปภาพในบรรทัดทั้งหมดอีกครั้ง โพสต์นี้อธิบายว่าข้อมูลคืออะไร: URI คืออะไร เหตุใดจึงเป็น Base64 การอินไลน์ส่งผลต่อแคชและประสิทธิภาพอย่างไร และกฎทั่วไปในการตัดสินใจว่าเมื่อใดการแลกเปลี่ยนจึงคุ้มค่า ข้อมูล: URL เป็นวิธีฝังทรัพยากรโดยตรงในไฟล์ HTML หรือ CSS แทนที่จะลิงก์ไปยังไฟล์ภายนอก ไวยากรณ์คือ data:mediaType;base64,encoded_bytes
ประเภทสื่อจะประกาศประเภทของทรัพยากรที่ตามมา เช่น image/svg+xml สำหรับ SVG, image/png สำหรับ PNG หรือ text/plain สำหรับข้อความ ธง ;base64 ระบุว่าเพย์โหลดมีการเข้ารหัส Base64 แทนที่จะเป็นข้อความที่เข้ารหัสเปอร์เซ็นต์ encoded_bytes เป็นข้อมูลจริง เมื่อเบราว์เซอร์พบข้อมูล: URL ในคุณสมบัติ href, src หรือพื้นหลังรูปภาพ เบราว์เซอร์จะถอดรหัส Base64 และแสดงผลทรัพยากรแบบอินไลน์ ไม่มีคำขอ HTTP เกิดขึ้นเนื่องจากมีทรัพยากรอยู่แล้ว ซึ่งฝังอยู่ในเอกสารหลัก การดำเนินการนี้จะบันทึกคำขอ HTTP หนึ่งหรือสองสามคำขอ ซึ่งสำคัญในโลก HTTP/1.1 ที่แต่ละคำขอมีค่าใช้จ่าย
การแคชและเส้นทางวิกฤติ - เหตุใดจึงมีการดาวน์โหลดไบต์แบบอินไลน์อีกครั้งในทุกเพจที่มีสไตล์ชีต
ในโลก HTTP/2 หรือ HTTP/3 ที่คำขอจำนวนมากสามารถมัลติเพล็กซ์ในการเชื่อมต่อเดียว การประหยัดจะลดลง การลดขนาดของการเข้ารหัส Base64 เกิดขึ้นทันทีและมีความสำคัญ ไอคอน SVG ที่มีขนาด 3 กิโลไบต์เมื่อบันทึกเป็นไฟล์ XML จะกลายเป็น 4 กิโลไบต์เมื่อเข้ารหัส Base64 และฝังเป็นข้อมูล: URI ต้องเพิ่มขนาดที่เพิ่มขึ้น 33% จากการเข้ารหัสในทุกหน้าที่มีสไตล์ชีต หากใช้ไอคอนบนสิบหน้า สไตล์ชีตจะถูกดาวน์โหลดสิบครั้ง ในแต่ละครั้งรวมรูปภาพที่เข้ารหัส 4 กิโลไบต์เดียวกันนั้นด้วย
หากไอคอนเป็นไฟล์แยกต่างหาก ไฟล์ต้นฉบับ 3 กิโลไบต์จะถูกดาวน์โหลดหนึ่งครั้งและแคชไว้ จากนั้นจึงใช้จากแคชในทั้งสิบหน้า ตัวเลือกทางเศรษฐกิจมีความชัดเจนสำหรับไอคอนส่วนใหญ่: ไฟล์ที่แยกจากกันมีขนาดเล็กกว่าโดยรวม ประโยชน์อินไลน์จะใช้เฉพาะเมื่อมีการใช้ไอคอนในหน้าเดียวหรือเพียงไม่กี่หน้าเท่านั้น และไอคอนมีความสำคัญอย่างยิ่งต่อหน้านั้น ไอคอน Fav ที่ปรากฏในทุกหน้าไม่เหมาะกับการแทรกในบรรทัด จะดีกว่าถ้าเป็นไฟล์แคชแยกต่างหาก
การแยกวิเคราะห์ต้นทุนบนไคลเอนต์ — วิธีจัดการสตริงอินไลน์ขนาดใหญ่โดย CSS และ HTML parsers อธิบายในเชิงคุณภาพ
ภาพประกอบแบบครั้งเดียวที่ใช้เฉพาะบนแลนดิ้งเพจอาจได้รับประโยชน์จากการอินไลน์เพื่อบันทึกคำขอ การแคชเอาชนะประโยชน์ส่วนใหญ่ของข้อมูลที่อินไลน์: URI ในสไตล์ชีต โดยทั่วไปสไตล์ชีตจะถูกแคชเป็นเวลาหลายวันหรือหลายสัปดาห์ เมื่อดาวน์โหลดสไตล์ชีตแล้ว ทรัพยากรทุกรายการในนั้นจะถูกดาวน์โหลดอีกครั้ง แม้ว่าเบราว์เซอร์จะแคชรูปภาพนั้นไว้แล้วก็ตาม หากสไตล์ชีตได้รับการอัปเดต ข้อมูลในบรรทัดทั้งหมดจะต้องได้รับการตรวจสอบความถูกต้องอีกครั้งหรือดาวน์โหลดใหม่ แม้ว่าจะมีการเปลี่ยนแปลงกฎ CSS เพียงกฎเดียวก็ตาม
สิ่งนี้ทำให้เกิดการขยายตัว: การเปลี่ยนสีหรือการเว้นวรรคจะทำให้มีการดาวน์โหลดสไตล์ชีตใหม่ทั้งหมด รวมถึงข้อมูลรูปภาพจำนวนกิโลไบต์ที่ไม่เปลี่ยนแปลง ไฟล์รูปภาพที่แยกต่างหากสามารถแคชได้อย่างอิสระด้วยส่วนหัวการหมดอายุของตัวเอง อัปเดตแยกกัน และนำกลับมาใช้ใหม่ในสไตล์ชีตและเพจต่างๆ แคชของเบราว์เซอร์จะมีประสิทธิภาพมากกว่าเมื่อทรัพยากรเป็นไฟล์แยกกันมากกว่าเมื่อฝังไว้ในเอกสารขนาดใหญ่ การแยกวิเคราะห์และการเรนเดอร์มีค่าใช้จ่ายเพิ่มขึ้นเมื่อมีการฝังสตริง Base64 ขนาดใหญ่ในสไตล์ชีต ตัวแยกวิเคราะห์ CSS ต้องอ่านสไตล์ชีตทั้งหมดก่อนที่จะใช้กฎ
ตัวอย่างการทำงาน: การแทรกไอคอน SVG ขนาดเล็กเป็นข้อความ วางมาร์กอัปลงในตัวเข้ารหัสและรวบรวมข้อมูล: URI ด้วยมือ
สไตล์ชีต 400 กิโลไบต์ที่มี Base64 แบบอินไลน์คือ 400 กิโลไบต์ของข้อความที่ต้องแยกวิเคราะห์ก่อนจึงจะสามารถใช้กฎใดๆ ได้ โปรแกรมแยกวิเคราะห์ HTML แสดงผลหน้าเว็บด้วยข้อมูลขนาดใหญ่: URI ในแอตทริบิวต์สไตล์หรือคุณสมบัติภาพพื้นหลังจะต้องถอดรหัส Base64 และสร้างภาพก่อนที่องค์ประกอบจะสามารถแสดงผลได้ สำหรับไอคอน SVG แบบธรรมดานี่เป็นเรื่องเล็กน้อย สำหรับรูปภาพที่ซับซ้อนมากขึ้นหรือไอคอนขนาดใหญ่ การถอดรหัสและการเรนเดอร์จะเกิดขึ้นบนเธรดหลัก ซึ่งอาจบล็อกการโต้ตอบได้ ต้นทุนเชิงคุณภาพนั้นมีอยู่จริงแต่วัดได้ยากหากไม่มีโปรไฟล์
ตามกฎแล้ว หากรูปภาพในบรรทัดมีขนาดใหญ่กว่าสองสามกิโลไบต์ ไฟล์ที่แยกจากกันก็จะเร็วกว่า ตัวอย่างที่ใช้งานได้แสดงให้เห็นถึงการแลกเปลี่ยนที่แน่นอน ใช้ไอคอนลูกศร SVG แบบธรรมดา ขนาด 1.2 กิโลไบต์ของ XML ที่เข้ารหัส Base64 จะกลายเป็น 1600 อักขระ หรือประมาณ 1.6 กิโลไบต์ โดยมีข้อมูล: URL นำหน้า กฎ CSS แยกต่างหากพร้อมภาพพื้นหลัง: url(/icons/arrow.svg) อาจเพิ่ม 40 bytes ลงในสไตล์ชีต ไฟล์ไอคอนจะถูกดาวน์โหลดครั้งเดียว แคช และนำกลับมาใช้ใหม่ การฝังในบรรทัดจะบันทึกคำขอ HTTP หนึ่งคำขอสำหรับไอคอนนั้น แต่เพิ่ม 1.6 กิโลไบต์ในทุกการโหลดสไตล์ชีต
กฎทั่วไปที่ยึดถือ — สินทรัพย์ขนาดเล็กที่มีความสำคัญและใช้งานครั้งเดียวแบบอินไลน์ ทุกอย่างอื่นเป็นไฟล์
หากสไตล์ชีตมีขนาด 50 กิโลไบต์ และใช้ร่วมกันใน 20 หน้า การแทรกไอคอนนั้นจะทำให้การดาวน์โหลดทั้งหมดเพิ่มขึ้น 32 กิโลไบต์ต่อการเข้าชมไซต์ คำขอ HTTP ที่บันทึกนั้นมีค่าใช้จ่ายไม่เกินสองสามร้อยไบต์ คำขอยังมัลติเพล็กซ์โดยอัตโนมัติใน HTTP/2, ซึ่งช่วยลดส่วนต่างของค่าใช้จ่าย การแลกเปลี่ยนแบบอินไลน์จะสูญเสียไปอย่างมาก เว้นแต่ว่าสไตล์ชีตมีขนาดเล็ก ไอคอนมีขนาดใหญ่ หรือไอคอนปรากฏบนหน้าเดียวและไม่มีที่อื่นเลย กฎทั่วไปที่รอดพ้นจากการตรวจสอบข้อเท็จจริงนั้นมีจำกัดและเฉพาะเจาะจง
คุณสามารถรวมเนื้อหาแบบใช้ครั้งเดียวที่มีขนาดเล็กและสำคัญได้ ลูกศร 200 ไบต์ SVG ที่ปรากฏเฉพาะบนเพจที่ผิดปกติเพียงเพจเดียวอาจถูกอินไลน์เพื่อบันทึกโอเวอร์เฮดของคำขอ อย่างอื่นควรแยกจากกัน ตรรกะของเส้นทางการเรนเดอร์ที่สำคัญมีความสำคัญ: หากต้องมองเห็นไอคอนได้ทันทีและเวลาในการโหลดทุก ๆ มิลลิวินาทีต้องเสียค่าใช้จ่ายในการแปลง การอินไลน์อาจชนะ สำหรับหน้าเว็บทั่วไปที่มีไอคอนทั่วไป ไฟล์ที่แยกจากกันจะดีกว่าเกือบทุกครั้ง ทดสอบทั้งสองวิธีด้วยเนื้อหาจริงของคุณและวัดการโหลดหน้าเว็บ อัตราการเข้าถึงแคช และขอน้ำตก
สิ่งนี้ไม่ครอบคลุมถึง — HTTP/2 และ HTTP/3 รายละเอียดมัลติเพล็กซ์และการบีบอัดรูปแบบภาพ
อย่าถือว่าอินไลน์เป็นการเพิ่มประสิทธิภาพโดยไม่มีการวัดผล วิธีที่ง่ายที่สุดที่จะจบลงด้วยสไตล์ชีทที่ป่องคือการอินไลน์แบบเพิ่มทีละน้อยโดยไม่ต้องวัดว่าการเพิ่มแต่ละครั้งนั้นเร็วกว่าจริงหรือไม่ ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณตัดสินใจได้ก่อนที่จะดำเนินการอินไลน์ วางมาร์กอัป SVG หรือแหล่งที่มาของไอคอนอื่นๆ ลงในเครื่องมือในรูปแบบข้อความ คลิกเข้ารหัสและตั้งค่าตัวเลือกเพื่อสร้างข้อมูล: URI เครื่องมือจะแสดงความยาวที่แน่นอนของข้อมูล: URL เปรียบเทียบกับขนาดของกฎ CSS ที่แยกต่างหากและตัวไฟล์เนื้อหาเอง
คำนวณจำนวนเพจที่ต้องใช้สไตล์ชีตร่วมกันเพื่อคุ้มทุนระหว่างไฟล์อินไลน์กับไฟล์แยกกัน รวบรวมข้อมูล: URI และทดสอบในหน้า HTML จริงก่อนที่คุณจะส่งไปยังสไตล์ชีต หาก URI ยาวกว่าสองสามร้อยอักขระ ค่าใช้จ่ายในการฝังน่าจะมากกว่าประโยชน์ของการบันทึกคำขอ ใช้เครื่องมือเพื่อทดสอบไอคอนและเนื้อหาจริงของคุณ จากนั้นวัดผลกระทบต่อเมตริกการโหลดหน้าเว็บจริงก่อนและหลังอินไลน์
ประเด็นสำคัญ: อินไลน์เท่าที่จำเป็นและวัดผล — วิธีที่ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณเข้ารหัสมาร์กอัป SVG และดูขนาดที่แน่นอนก่อนที่คุณจะคอมมิต
แนวทางการปฏิบัติงานคือการเลือกสรรเกี่ยวกับการอินไลน์ ไอคอนที่ใช้กับทุกหน้าหรือหลายหน้าเป็นไฟล์แคชที่แยกจากกัน ไอคอนที่ใช้ในหนึ่งหน้าหรือมีความสำคัญอย่างยิ่งต่อการลงสีครั้งแรกสามารถอยู่ในบรรทัดได้ วัดผลการแลกเปลี่ยนกับเนื้อหาและเพจจริงของคุณ แทนที่จะทำตามคำแนะนำทั่วไป ใช้ตัวเข้ารหัสและตัวถอดรหัส Base64 เพื่อดูขนาดที่แน่นอนของเนื้อหาที่แทรกในบรรทัดก่อนที่คุณจะเพิ่มลงในสไตล์ชีต การลงโทษขนาดเป็นจริงและทวีคูณในทุกการดูหน้าเว็บ
การแคชและการร้องขอมัลติเพล็กซ์ทำให้ประโยชน์เดิมของการอินไลน์มีความสำคัญน้อยลง สำหรับแอปพลิเคชันสมัยใหม่ส่วนใหญ่ สไตล์ชีตที่เล็กลงและประสิทธิภาพแคชที่ดีขึ้นจากไฟล์ที่แยกจากกันมีมากกว่าค่าใช้จ่ายในการร้องขอ อินไลน์เท่าที่จำเป็น วัดผลลัพธ์และไว้วางใจการวัดมากกว่าสัญชาตญาณ