หนึ่งขนาดเหมาะกับบางคน: คำแนะนำเกี่ยวกับโซลูชันอิมเมจการออกแบบเว็บที่ตอบสนอง

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

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

ในการแสวงหารูปภาพบนเว็บที่ตอบสนอง

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

แท็ก <img> มีเฉพาะแอตทริบิวต์ต้นทางที่ลิงก์ไปยังรูปภาพโดยตรงเท่านั้น ไม่มีวิธีกำหนดประเภทรูปภาพที่ถูกต้องโดยไม่ต้องใช้โปรแกรมเสริมใดๆ

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

แล้วเว็บไซต์มีไว้ทำอะไร?

โซลูชันการปรับขนาดภาพที่ตอบสนองต่อแบ็คเอนด์

ยกเว้นไซต์/โดเมนย่อยสำหรับมือถือเท่านั้น เราเหลือเพียงตัวแทนผู้ใช้ (UA) ที่ดมกลิ่นและใช้เพื่อให้บริการรูปภาพที่มีขนาดถูกต้องกลับไปยังผู้ใช้ อย่างไรก็ตาม นักพัฒนาซอฟต์แวร์ทุกคนสามารถยืนยันได้ว่าโซลูชันนี้ไม่น่าเชื่อถือเพียงใด สตริง UA ใหม่ปรากฏขึ้นตลอดเวลา ทำให้ยากต่อการดูแลและอัปเดตรายการที่ครอบคลุม และแน่นอนว่าสิ่งนี้ไม่ได้คำนึงถึงความไม่น่าเชื่อถือของสตริง UA ที่ปลอมแปลงได้ง่ายตั้งแต่แรก

รูปภาพที่ปรับเปลี่ยนได้

อย่างไรก็ตาม โซลูชันฝั่งเซิร์ฟเวอร์บางตัวก็ควรค่าแก่การพิจารณา Adaptive Images เป็นโซลูชันที่ยอดเยี่ยมสำหรับผู้ที่ต้องการแก้ไขรูปภาพที่ตอบสนองด้านหลัง ไม่ต้องการมาร์กอัปพิเศษใด ๆ แต่ใช้ไฟล์ JavaScript ขนาดเล็กแทนและทำงานหนักส่วนใหญ่ในไฟล์แบ็คเอนด์ ใช้เซิร์ฟเวอร์ที่กำหนดค่า PHP และ nginx นอกจากนี้ยังไม่ต้องอาศัยการดมกลิ่นของ UA แต่จะตรวจสอบความกว้างของหน้าจอแทน Adaptive Images ใช้งานได้ดีสำหรับการย่อขนาดรูปภาพ แต่ยังสะดวกสำหรับเมื่อรูปภาพขนาดใหญ่ต้องการทิศทางของงานศิลปะ เช่น การลดขนาดรูปภาพด้วยเทคนิคต่างๆ เช่น การครอบตัดและการหมุน ไม่ใช่แค่การปรับอัตราส่วน

เซ็นฉะ ทัช

Sencha Touch เป็นโซลูชันอิมเมจการออกแบบที่ตอบสนองต่อแบ็คเอนด์อีกตัวหนึ่ง แม้ว่าจะเป็นการดีกว่าถ้าเรียกว่าเป็นโซลูชันของบุคคลที่สาม Sencha Touch จะปรับขนาดภาพตามด้วยการดม UA ด้านล่างนี้เป็นตัวอย่างพื้นฐานของบริการทำงาน:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

นอกจากนี้ยังมีตัวเลือกในการระบุขนาดภาพ ในกรณีที่เราไม่ต้องการให้ Sencha ปรับขนาดภาพโดยอัตโนมัติ

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

โซลูชั่นฟรอนต์เอนด์

ในช่วงไม่กี่ครั้งที่ผ่านมา มีการปรับปรุงอย่างมากในด้านเบราว์เซอร์เพื่อจัดการกับรูปภาพที่ตอบสนอง

องค์ประกอบ <picture> ได้รับการแนะนำและรับรองในข้อกำหนด HTML5 โดย W3C ขณะนี้ยังไม่มีให้บริการอย่างแพร่หลายในเบราว์เซอร์ทั้งหมด แต่จะใช้งานได้ไม่นานก่อนที่จะมีให้ใช้งานจริง ก่อนหน้านั้น เราพึ่งพา JavaScript polyfills สำหรับองค์ประกอบ Polyfills ยังเป็นโซลูชันที่ยอดเยี่ยมสำหรับเบราว์เซอร์รุ่นเก่าที่ไม่มีองค์ประกอบดังกล่าว

นอกจากนี้ยังมีกรณีของแอตทริบิวต์ srcset ที่พร้อมใช้งานสำหรับเบราว์เซอร์ที่ใช้ webKit หลายตัวสำหรับองค์ประกอบ <img> สามารถใช้ได้โดยไม่มี JavaScript และเป็นทางออกที่ดีหากเบราว์เซอร์ที่ไม่ใช่ webKit ถูกละเลย เป็นช่องว่างหยุดที่มีประโยชน์สำหรับกรณีแปลก ๆ ที่วิธีแก้ไขปัญหาอื่น ๆ ล้มเหลว แต่ไม่ควรพิจารณาว่าเป็นโซลูชันที่ครอบคลุม

Picturefill

Picturefill เป็นไลบรารี polyfill สำหรับองค์ประกอบ <picture> มันเป็นหนึ่งในไลบรารี่ที่ได้รับความนิยมมากที่สุดในบรรดาโซลูชั่นฟรอนต์เอนด์สำหรับปัญหาการปรับขนาดและสเกลรูปภาพที่ตอบสนอง มีสองรุ่น; Picturefill v1 เลียนแบบองค์ประกอบ <picture> โดยใช้ span ในขณะที่ Picturefill v2 ใช้องค์ประกอบ <picture> ในเบราว์เซอร์ที่มีอยู่แล้วและจัดเตรียม polyfill สำหรับองค์ประกอบเดิม (เช่น สำหรับ IE >= IE9) มีข้อ จำกัด และวิธีแก้ไข โดยเฉพาะอย่างยิ่งสำหรับ Android 2.3 ซึ่งเป็นตัวอย่างที่แอตทริบิวต์ img srcset มาช่วยโดยบังเอิญ ด้านล่างเป็นตัวอย่างมาร์กอัปสำหรับการใช้ Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

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

Imager.js

Imager.js เป็นห้องสมุดที่สร้างขึ้นโดยทีมงาน BBC News เพื่อสร้างภาพที่ตอบสนองได้โดยใช้แนวทางที่แตกต่างไปจาก Picturefill แม้ว่า Picturefill จะพยายามนำองค์ประกอบ <picture> ไปยังเบราว์เซอร์ที่ไม่รองรับ Imager.js จะเน้นที่การดาวน์โหลดเฉพาะภาพที่เหมาะสมในขณะที่คอยระวังความเร็วของเครือข่าย นอกจากนี้ยังรวมการโหลดแบบ Lazy Loading โดยไม่ต้องอาศัยไลบรารีของบุคคลที่สาม ทำงานโดยใช้องค์ประกอบตัวยึดตำแหน่งและแทนที่ด้วยองค์ประกอบ <img> โค้ดตัวอย่างด้านล่างแสดงลักษณะการทำงานนี้:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

HTML ที่แสดงผลจะมีลักษณะดังนี้:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

การสนับสนุนเบราว์เซอร์นั้นดีกว่า Picturefill มากเนื่องจากเป็นโซลูชันที่ใช้งานได้จริงมากกว่าการคิดล่วงหน้า

แหล่งสับเปลี่ยน

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

ไลบรารี JavaScript ที่โดดเด่นอื่นๆ ได้แก่:

• HiSRC - ปลั๊กอิน jQuery สำหรับรูปภาพที่ตอบสนอง การพึ่งพา jQuery อาจเป็นปัญหา
• Mobify.js - ไลบรารีทั่วไปสำหรับเนื้อหาที่ตอบสนอง ซึ่งรวมถึงรูปภาพ สไตล์ชีต และแม้แต่ JavaScript มัน 'จับ' DOM ก่อนโหลดทรัพยากร Mobify เป็นไลบรารี่แบบครอบคลุมที่มีประสิทธิภาพ แต่อาจใช้ความพยายามมากเกินไปหากเป้าหมายเป็นเพียงภาพที่ตอบสนอง

สรุป

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

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

• เบราว์เซอร์รุ่นเก่ามีปัญหาหรือไม่? หากไม่เป็นเช่นนั้น ให้ลองใช้แนวทางที่ทันสมัยกว่านี้ (เช่น Picturefill, srcset attribute)
• เวลาตอบสนองมีความสำคัญหรือไม่? หากไม่เป็นเช่นนั้น ให้ไปที่โซลูชันของบริษัทอื่นหรือส่วนหลัง
• โซลูชันควรอยู่ในองค์กรหรือไม่ โซลูชันของบุคคลที่สามจะถูกตัดออกอย่างชัดเจน
• มีรูปภาพจำนวนมากบนไซต์ที่พยายามเปลี่ยนไปใช้รูปภาพที่ตอบสนองหรือไม่ มีความกังวลเกี่ยวกับการตรวจสอบความถูกต้องหรือแท็กความหมาย (หรือแท็กที่ไม่ใช่ความหมาย) หรือไม่? สิ่งนี้จะต้องใช้โซลูชันแบ็คเอนด์เพื่อกำหนดเส้นทางคำขอรูปภาพไปยังบางอย่างเช่น Adaptive Images
• การกำกับศิลป์เป็นปัญหาหรือไม่ (สำหรับรูปภาพขนาดใหญ่ที่มีข้อมูลจำนวนมากโดยเฉพาะ) ไลบรารีอย่าง Picturefill จะเป็นทางออกที่ดีกว่าสำหรับสถานการณ์ดังกล่าว นอกจากนี้ โซลูชันแบ็กเอนด์ใดๆ ก็ใช้ได้เช่นกัน
• มีความกังวลเกี่ยวกับการขาด JavaScript หรือไม่? โซลูชันฟรอนต์เอนด์ใดๆ ก็ตามจะไม่เป็นปัญหา ซึ่งทำให้ตัวเลือกแบ็คเอนด์หรือบุคคลที่สามต้องอาศัยการดมกลิ่นของ UA
• มีลำดับความสำคัญสำหรับเวลาตอบสนองมือถือมากกว่าเวลาตอบสนองเดสก์ท็อปหรือไม่ ห้องสมุดเช่น Source Shuffling อาจเหมาะสมกว่า
• จำเป็นต้องจัดเตรียมพฤติกรรมที่ตอบสนองต่อทุกแง่มุมของเว็บไซต์ ไม่ใช่แค่รูปภาพหรือไม่ Mobify.js อาจทำงานได้ดีขึ้น
• โลกที่สมบูรณ์แบบได้รับการบรรลุหรือไม่? ใช้ CSS เท่านั้น display:none วิธี!