ฉันควรฝังรูปภาพเป็น data / base64 ใน CSS หรือ HTML

เพื่อลดจำนวนคำขอบนเซิร์ฟเวอร์ฉันได้ฝังรูปภาพ (PNG & SVG) เป็น BASE64 ลงใน css โดยตรง (อัตโนมัติในกระบวนการสร้าง)

แบบนี้:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

นี่เป็นแนวทางปฏิบัติที่ดีหรือไม่? มีเหตุผลบางประการที่ควรหลีกเลี่ยงสิ่งนี้หรือไม่? มีเบราว์เซอร์หลักบางตัวที่ไม่รองรับ data url หรือไม่?

คำถามโบนัส: การทำเช่นนี้กับ CSS & JS ยังสมเหตุสมผลหรือไม่

นี่เป็นแนวทางปฏิบัติที่ดีหรือไม่? มีเหตุผลบางประการที่ควรหลีกเลี่ยงสิ่งนี้หรือไม่?

โดยปกติแล้วเป็นแนวทางปฏิบัติที่ดีสำหรับอิมเมจ CSS ขนาดเล็กมากที่จะใช้ร่วมกันเท่านั้น (เช่น CSS สไปรต์) เมื่อความเข้ากันได้ของ IE ไม่สำคัญและการบันทึกคำขอนั้นสำคัญกว่าความสามารถในการแคช

มีข้อเสียที่น่าสังเกตหลายประการ:

• ไม่ทำงานเลยใน IE6 และ 7

• ใช้งานได้กับทรัพยากรที่มีขนาดไม่เกิน 32k ใน IE8เท่านั้น นี่คือขีด จำกัด ที่ใช้หลังจากการเข้ารหัส base64 กล่าวอีกนัยหนึ่งความยาวไม่เกิน 32768 อักขระ

• มันบันทึกคำขอ แต่ขยายหน้า HTML แทน! และทำให้ภาพไม่สามารถแคชได้ พวกเขาจะโหลดทุกครั้งที่โหลดเพจที่มีหรือสไตล์ชีต

• การเข้ารหัส Base64 ขยายขนาดภาพ 33%

• หากให้บริการในแหล่งข้อมูล gzipped data:รูปภาพแทบจะเป็นปัญหาอย่างมากกับทรัพยากรของเซิร์ฟเวอร์! โดยปกติแล้วภาพจะใช้ CPU อย่างเข้มข้นในการบีบอัดโดยลดขนาดลงเพียงเล็กน้อย

คำตอบทั่วไปที่นี่ดูเหมือนว่าไม่จำเป็นต้องใช้ด้วยเหตุผลหลายประการ อย่างไรก็ตามสิ่งเหล่านี้ดูเหมือนจะละเลยพฤติกรรมของแอปสมัยใหม่และกระบวนการสร้าง

เป็นไปไม่ได้เลย (และค่อนข้างง่ายจริงๆ) ในการออกแบบกระบวนการง่ายๆที่จะเดินผ่านรูปภาพโฟลเดอร์และจะสร้าง CSS เดียวพร้อมรูปภาพทั้งหมดของโฟลเดอร์นี้

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

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

1. หน้าที่มีรูปภาพหลายรูปที่ "แตกต่างกัน" ได้ไม่ยาก
2. การเดินทางไปกลับเซิร์ฟเวอร์เป็นปัญหาคอขวดที่แท้จริง (คิดว่าเป็นอุปกรณ์เคลื่อนที่)
3. ความเร็ว (ถึงระดับมิลลิวินาที) เป็นสิ่งที่สำคัญมากสำหรับกรณีการใช้งานของคุณ
4. คุณไม่สนใจ (เท่าที่ควรหากคุณต้องการให้เว็บดำเนินต่อไป) เกี่ยวกับ IE5 และ IE6

มุมมองของฉัน.

ไม่ใช่วิธีปฏิบัติที่ดี เบราว์เซอร์บางตัวไม่รองรับ URI ข้อมูล (เช่น IE 6 และ 7) หรือการรองรับมี จำกัด (เช่น 32KB สำหรับ IE8)

ดูบทความ Wikipedia นี้เพื่อดูรายละเอียดทั้งหมดเกี่ยวกับข้อเสีย URI ของข้อมูล:

• โครงร่าง URI ข้อมูล

ข้อเสีย

• URI ข้อมูลจะไม่ถูกแคชแยกต่างหากจากเอกสารที่มีอยู่ (เช่นไฟล์ CSS หรือ HTML) ดังนั้นข้อมูลจะถูกดาวน์โหลดทุกครั้งที่มีการดาวน์โหลดเอกสารที่มีอีกครั้ง
• เนื้อหาจะต้องเข้ารหัสใหม่และฝังใหม่ทุกครั้งที่มีการเปลี่ยนแปลง
• Internet Explorer ถึงเวอร์ชัน 7 (ประมาณ 15% ของตลาด ณ เดือนมกราคม 2554) ขาดการสนับสนุน
• Internet Explorer 8 จำกัด URI ของข้อมูลไว้ที่ความยาวสูงสุด 32 KB
• ข้อมูลจะรวมเป็นสตรีมอย่างง่ายและสภาพแวดล้อมการประมวลผลหลายอย่าง (เช่นเว็บเบราว์เซอร์) อาจไม่รองรับการใช้คอนเทนเนอร์ (เช่นmultipart/alternativeหรือmessage/rfc822) เพื่อให้มีความซับซ้อนมากขึ้นเช่นข้อมูลเมตาการบีบอัดข้อมูลหรือการต่อรองเนื้อหา
• URI ของข้อมูลที่เข้ารหัส Base64 มีขนาดใหญ่กว่าไบนารีเทียบเท่า 1/3 (อย่างไรก็ตามค่าใช้จ่ายนี้จะลดลงเหลือ 2-3% หากเซิร์ฟเวอร์ HTTP บีบอัดการตอบสนองโดยใช้ gzip)
• URI ของข้อมูลทำให้ซอฟต์แวร์รักษาความปลอดภัยกรองเนื้อหาได้ยากขึ้น

ฉันใช้ data-uri เป็นเวลาประมาณหนึ่งเดือนและฉันเพิ่งหยุดใช้เพราะมันทำให้สไตล์ชีตของฉันมีขนาดใหญ่มาก

Data-uri ทำงานใน IE6 / 7 (คุณเพียงแค่ต้องให้บริการไฟล์mhtmlไปยังเบราว์เซอร์เหล่านั้น)

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

เป็นเรื่องดีที่เรามีเทคนิคนี้ แต่ฉันจะไม่ใช้มันมากเกินไปในอนาคต ฉันขอแนะนำให้ลองใช้ดูเพื่อให้คุณรู้ด้วยตัวคุณเอง

ฉันชอบใช้ CSS Sprites เพื่อรวมรูปภาพและบันทึกตามคำขอมากกว่า ฉันไม่เคยลองใช้เทคนิค base64 แต่ดูเหมือนจะใช้ไม่ได้ใน IE6 และ IE7 นอกจากนี้ยังหมายความว่าหากมีการเปลี่ยนแปลงรูปภาพใด ๆ คุณจะต้องส่งภาพที่หายไปทั้งหมดอีกครั้งเว้นแต่คุณจะมีไฟล์ CSS หลายไฟล์แน่นอน

ฉันไม่รู้เกี่ยวกับแนวทางปฏิบัติทั่วไปที่ดีที่สุด แต่ฉันไม่อยากเห็นเรื่องแบบนั้นถ้าฉันสามารถช่วยได้ :)

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

มีสาเหตุที่คุณคิดว่ามีคำขอไปยังเซิร์ฟเวอร์มากเกินไปในขณะนี้หรือไม่?

ฉันขอแนะนำสำหรับรูปภาพขนาดเล็กที่ใช้บ่อยเช่นไอคอนทั่วไปของเว็บแอปพลิเคชัน

• เล็ก ๆ เนื่องจากการเข้ารหัส Base64 จะเพิ่มขนาด
• มักใช้เนื่องจากสิ่งนี้แสดงให้เห็นถึงเวลาในการโหลดครั้งแรกที่นานขึ้น

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

ข้อมูลเพิ่มเติมรวบรวมไว้ที่นี่: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/