การบีบอัดและการเข้ารหัสอัตโนมัติ

ทำให้การสร้างแหล่งที่มาของรูปภาพที่มีประสิทธิภาพสูงเป็นส่วนหนึ่งของกระบวนการพัฒนาที่ราบรื่น

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

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

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

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

การบีบอัดและการเข้ารหัสอัตโนมัติ

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

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

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

สำหรับการประมวลผลนั้น มีไลบรารีการประมวลผลรูปภาพแบบโอเพนซอร์สจำนวนมากที่ให้วิธีการแปลง แก้ไข และแก้ไขรูปภาพเป็นกลุ่ม ซึ่งจะแข่งขันด้านความเร็ว ประสิทธิภาพ และความน่าเชื่อถือ ไลบรารีการประมวลผลเหล่านี้ช่วยให้คุณใช้การตั้งค่าการเข้ารหัสและการบีบอัดกับไดเรกทอรีของรูปภาพทั้งชุดได้ในครั้งเดียวโดยไม่ต้องเปิดซอฟต์แวร์แก้ไขรูปภาพ และในลักษณะที่รักษาแหล่งที่มาของรูปภาพต้นฉบับในกรณีที่ต้องมีการปรับเปลี่ยนการตั้งค่าดังกล่าวอย่างรวดเร็ว คีย์เหล่านี้มีจุดมุ่งหมายในการเรียกใช้ในหลากหลายบริบท ตั้งแต่สภาพแวดล้อมในการพัฒนาซอฟต์แวร์ในเครื่องของคุณไปจนถึงเว็บเซิร์ฟเวอร์ ตัวอย่างเช่น ImageMin ที่เน้นการบีบอัดสำหรับ Node.js สามารถขยายเพื่อให้เหมาะกับแอปพลิเคชันที่เฉพาะเจาะจงผ่านปลั๊กอินแบบข้ามแพลตฟอร์ม ขณะที่ ImageMagick แบบข้ามแพลตฟอร์มและ Sharp แบบ Node.js มาพร้อมกับฟีเจอร์จำนวนมหาศาลที่พร้อมใช้งานทันที

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

เครื่องมือและเวิร์กโฟลว์สำหรับการพัฒนาในพื้นที่

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

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

แม้ว่าการใช้ซอฟต์แวร์ตัดต่อรูปภาพจะเป็นงานที่ต้องทำซ้ำและใช้เวลานาน แต่โปรแกรมทำงานอย่างเช่น Gulp ก็ได้รับการออกแบบมาเพื่อทำให้การทำซ้ำในลักษณะนี้เป็นไปโดยอัตโนมัติ ปลั๊กอิน gulp-responsive ซึ่งใช้ Sharp เป็นหนึ่งในตัวเลือกจำนวนมากที่มีรูปแบบคล้ายกัน ได้แก่ รวบรวมไฟล์ทั้งหมดในไดเรกทอรีต้นทาง เข้ารหัสไฟล์อีกครั้ง และบีบอัดไฟล์ตามค่าชวเลข "คุณภาพ" มาตรฐานเดียวกับอย่างที่คุณเรียนรู้จากรูปแบบรูปภาพและการบีบอัด ไฟล์ที่ได้จะแสดงผลเป็นเส้นทางที่คุณกำหนด และพร้อมให้อ้างอิงในแอตทริบิวต์ src ขององค์ประกอบ img ที่แสดงต่อผู้ใช้ โดยที่ไฟล์ต้นฉบับจะยังคงอยู่

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.webp = function() {
  return src('./src-img/*')
    .pipe(respimg({
      '*': [{
        quality: 70,
        format: ['webp', 'jpeg'],
        progressive: true
      }]
  }))
  .pipe(dest('./img/'));
}

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

หากต้องการส่งออกไฟล์หลายไฟล์ คุณจะต้องส่งผ่านออบเจ็กต์การกำหนดค่าหลายรายการ ซึ่งเป็นวิธีเดียวกัน นอกเหนือจากการเพิ่มคีย์ width และค่าเป็นพิกเซล

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.default = function() {
  return src('./src-img/*')
    .pipe(respimg({
    '*': [{
            width: 1000,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-1000' }
            },
            {
            width: 800,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-800' }
            },
            {
            width: 400,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-400' },
        }]
        })
    )
    .pipe(dest('./img/'));
}

ในกรณีของตัวอย่างข้างต้น รูปภาพต้นฉบับ (monarch.png) มีขนาดใหญ่กว่า 3.3MB ไฟล์ขนาดใหญ่ที่สุดที่สร้างโดยงานนี้ (monarch-1000.jpeg) คือประมาณ 150 KB ขนาดเล็กที่สุด monarch-400.web มีขนาดเพียง 32 KB

[10:30:54] Starting 'default'...
[10:30:54] gulp-responsive: monarch.png -> monarch-400.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-800.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-400.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-800.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.webp
[10:30:54] gulp-responsive: Created 6 images (matched 1 of 1 image)
[10:30:54] Finished 'default' after 374 ms

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

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

มาร์กอัปรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ในทางปฏิบัติ

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

srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w"

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

ตามที่คุณได้เรียนรู้เกี่ยวกับรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ คุณควรใช้องค์ประกอบ <picture> เพื่อจัดการรูปแบบ WebP หรือ JPEG สำรองได้อย่างราบรื่น ในกรณีนี้ คุณจะใช้แอตทริบิวต์ type ร่วมกับ srcset

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

อย่างที่คุณได้ทราบไป เบราว์เซอร์ที่รองรับ WebP จะจดจำเนื้อหาของแอตทริบิวต์ type และเลือกแอตทริบิวต์ srcset ขององค์ประกอบ <source> นั้นเป็นรายการตัวเลือกรูปภาพ เบราว์เซอร์ที่ไม่รู้จัก image/webp เป็นประเภทสื่อที่ถูกต้องจะไม่สนใจ <source> นี้และใช้แอตทริบิวต์ srcset ขององค์ประกอบ <img> ภายในแทน

อีก 1 สิ่งที่ควรพิจารณาในแง่ของการรองรับเบราว์เซอร์ คือ เบราว์เซอร์ที่ไม่รองรับมาร์กอัปรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์จะยังคงต้องใช้รูปภาพสำรอง หรือเราอาจเสี่ยงที่รูปภาพจะเสียในบริบทการท่องเว็บเก่าๆ โดยเฉพาะ เนื่องจากเบราว์เซอร์เหล่านี้ไม่สนใจ <picture>, <source> และ srcset ทั้งหมด เราจึงต้องการระบุแหล่งที่มาเริ่มต้นในแอตทริบิวต์ src ของ <img> ภายใน

เนื่องจากการปรับขนาดรูปภาพลงอย่างราบรื่นเป็นภาพรองรับการเข้ารหัส JPEG ได้รับการรองรับในระดับสากล ตัวเลือกที่เหมาะสมคือ JPEG ที่มีขนาดใหญ่ที่สุด

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img src="filename-1000.jpg" srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

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

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

เครื่องมือสำหรับการวิเคราะห์แอตทริบิวต์ sizes นั้นมีประโยชน์แน่นอนอยู่แล้ว แต่จะยิ่งมีคุณค่ามากขึ้นในฐานะเครื่องมือในการสร้างแอตทริบิวต์เหล่านั้นขายส่ง อย่างที่คุณทราบ ไวยากรณ์ srcset และ sizes มีวัตถุประสงค์เพื่อเพิ่มประสิทธิภาพคำขอสำหรับชิ้นงานรูปภาพในลักษณะที่ลื่นไหล แม้ว่าจะไม่ใช่สิ่งที่ควรใช้ในเวอร์ชันที่ใช้งานจริง แต่ค่าตัวยึดตำแหน่ง sizes เริ่มต้นซึ่งเป็น 100vw ถือว่าเหมาะสมอย่างยิ่งเมื่อทำงานกับเลย์เอาต์ของหน้าในสภาพแวดล้อมการพัฒนาในเครื่อง เมื่อใช้รูปแบบเลย์เอาต์เรียบร้อยแล้ว การเรียกใช้ respImageLint จะแสดงแอตทริบิวต์ sizes ที่ปรับให้เหมาะกับคุณ ซึ่งคุณจะคัดลอกและวางลงในมาร์กอัปได้ในระดับรายละเอียดที่มากกว่าแอตทริบิวต์ที่เขียนด้วยมือ

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

แน่นอนว่าหากคุณใช้เฟรมเวิร์กการแสดงผลฝั่งไคลเอ็นต์ เช่น React หรือ Vue อยู่แล้ว ก็เป็นหนี้สินที่คุณต้องทำอยู่แล้ว และในกรณีเหล่านั้น การใช้ Lazysizes จะทำให้แอตทริบิวต์ sizes ของคุณกลายเป็นสิ่งที่จับต้องได้แทบจะทั้งหมด ยิ่งไปกว่านั้น Lazysizes จะกลายเป็นโพลีฟิลล์สำหรับลักษณะการทำงานของเบราว์เซอร์ที่ได้มาตรฐานใหม่อย่างมีประสิทธิภาพ เนื่องจาก sizes="auto" สำหรับรูปภาพที่โหลดแบบ Lazy Loading นั้นได้รับความเห็นพ้องและมีการติดตั้งใช้งานแบบดั้งเดิม