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

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

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

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

เพียงแค่มีแอตทริบิวต์ที่มาที่เชื่อมโยงโดยตรงกับภาพเอง คุณไม่มีทางกำหนดประเภทของรูปภาพที่ถูกต้องได้โดยไม่ต้องมีการเพิ่มเติมใด ๆ

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

แล้วเว็บไซต์ควรทำอย่างไร?

Back-End Solutions สำหรับการปรับขนาดภาพ

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

รูปภาพที่ปรับแต่งได้

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

แตะ Sencha

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

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

โซลูชั่นส่วนหน้า

ในช่วงไม่กี่ครั้งที่ผ่านมามีการปรับปรุงครั้งใหญ่ในฝั่งเบราว์เซอร์เพื่อแก้ไขปัญหาภาพที่ตอบสนอง

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

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

ออกแบบอย่างไรให้ตอบสนอง

Picturefill

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

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

Imager.js

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

new Imager({ availableWidths: [480, 768, 1200] });

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

new Imager({ availableWidths: [480, 768, 1200] });

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

การสลับแหล่งที่มา

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

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

• HiSRC - ปลั๊กอิน jQuery สำหรับภาพที่ตอบสนอง การใช้ jQuery อาจเป็นปัญหาได้

  เว็บตรวจสอบโทเค็น angularjs api

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

สรุป

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

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

• เบราว์เซอร์เดิมเป็นปัญหาหรือไม่? หากไม่เป็นเช่นนั้นให้พิจารณาใช้แนวทางที่ทันสมัยกว่า (เช่น Picturefill, attribute srcset)

• เวลาตอบสนองมีความสำคัญหรือไม่? หากไม่เป็นเช่นนั้นให้ไปที่โซลูชันแบ็คเอนด์หรือเอาต์ซอร์ซ

• โซลูชันควรเป็นแบบภายในหรือไม่? เห็นได้ชัดว่าตัวเลือกจากภายนอกไม่อยู่ในคำถาม

• มีรูปภาพจำนวนมากบนไซต์ที่พยายามเปลี่ยนเป็นรูปภาพที่ตอบสนองหรือไม่ มีข้อกังวลเกี่ยวกับการตรวจสอบความถูกต้องหรือป้ายกำกับความหมาย (หรือป้ายกำกับที่ไม่ใช่ความหมาย) หรือไม่? สิ่งนี้จะต้องใช้โซลูชันแบ็กเอนด์เพื่อแนะนำคำขอรูปภาพไปยังสิ่งต่างๆเช่น Adaptive Images

• ทิศทางศิลปะเป็นปัญหาหรือไม่ (โดยเฉพาะสำหรับภาพขนาดใหญ่ที่มีข้อมูลจำนวนมาก) ไลบรารีเช่น Picturefill อาจเป็นทางออกที่ดีกว่าสำหรับสถานการณ์ดังกล่าว นอกจากนี้โซลูชันส่วนหลังใด ๆ ก็สามารถทำงานได้เช่นกัน

• มีข้อกังวลเกี่ยวกับ JavaScript หรือไม่? โซลูชันส่วนหน้าจะไม่เป็นปัญหาโดยมีตัวเลือกเช่นแบ็คเอนด์หรือเอาต์ซอร์ซที่ต้องพึ่งพาการติดตาม UA

• ลำดับความสำคัญของเวลาตอบสนองของอุปกรณ์เคลื่อนที่เทียบกับเวลาตอบสนองบนเดสก์ท็อปหรือไม่ ไลบรารีเช่น Source Shuffling ควรเหมาะสมที่สุดสำหรับกรณีนั้น

• จำเป็นต้องมีพฤติกรรมที่ตอบสนองต่อทุกแง่มุมของไซต์ไม่ใช่แค่รูปภาพเท่านั้น Mobify สามารถทำงานได้ดีขึ้น

• โลกที่สมบูรณ์แบบมาถึงแล้วหรือยัง? ดังนั้นใช้การประมาณ CSS เท่านั้น display:none!