แนวทางปฏิบัติแนะนำสำหรับภาพสไลด์

เพิ่มประสิทธิภาพภาพสไลด์เพื่อประสิทธิภาพและความสามารถในการใช้งาน

Katie Hempenius

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

บทความนี้จะกล่าวถึงประสิทธิภาพและแนวทางปฏิบัติแนะนำสำหรับ UX ของภาพสไลด์

การแสดง

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

• LCP (การแสดงผลเนื้อหาขนาดใหญ่ที่สุด)

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

• INP (การโต้ตอบกับ Next Paint)

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

• CLS (Cumulative Layout Shift)

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

แนวทางปฏิบัติแนะนำด้านประสิทธิภาพ

โหลดเนื้อหาภาพสไลด์โดยใช้ HTML

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

<div class="slides">
  <img src="https://example.com/cat1.jpg">
  <img src="https://example.com/cat2.jpg">
  <img src="https://example.com/cat3.jpg">
</div>

const slides = document.querySelector(".slides");
const newSlide = document.createElement("img");
newSlide.src = "htttp://example.com/cat1.jpg";
slides.appendChild(newSlide);

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

หลีกเลี่ยงการเลื่อนเลย์เอาต์

การเปลี่ยนสไลด์และการควบคุมการนำทางเป็นแหล่งที่มาของการเปลี่ยนแปลงเลย์เอาต์ในภาพสไลด์ที่พบได้บ่อยที่สุด 2 แหล่ง ได้แก่

• การเปลี่ยนสไลด์: การเปลี่ยนเลย์เอาต์ที่เกิดขึ้นระหว่างการเปลี่ยนสไลด์นั้นมักเกิดจากการอัปเดตคุณสมบัติที่ทำให้เกิดเลย์เอาต์ขององค์ประกอบ DOM ตัวอย่างพร็อพเพอร์ตี้เหล่านี้ ได้แก่ left, top, width และ marginTop เพื่อหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ ให้ใช้พร็อพเพอร์ตี้ CSS transform เพื่อเปลี่ยนองค์ประกอบเหล่านี้ การสาธิตนี้แสดงวิธีใช้ transform เพื่อสร้างภาพสไลด์พื้นฐาน

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

สาเหตุที่พบบ่อยของความสับสนเกี่ยวกับการวัด CLS สำหรับภาพสไลด์มีดังนี้

• ภาพสไลด์เล่นอัตโนมัติ: การเปลี่ยนสไลด์เป็นสาเหตุที่พบบ่อยที่สุดของการเปลี่ยนเลย์เอาต์ที่เกี่ยวข้องกับภาพสไลด์ ในภาพสไลด์ที่ไม่ได้เล่นอัตโนมัติ การเปลี่ยนแปลงเลย์เอาต์เหล่านี้มักเกิดขึ้นภายใน 500 มิลลิวินาทีหลังจากการโต้ตอบของผู้ใช้และจึงไม่นับรวม Cumulative Layout Shift (CLS) อย่างไรก็ตาม สำหรับภาพสไลด์แบบเล่นอัตโนมัติ การเปลี่ยนเลย์เอาต์เหล่านี้อาจนับรวมกับ CLS ไม่เพียงเท่านั้น แต่ยังทำซ้ำไปเรื่อยๆ อย่างไม่มีกำหนดได้ด้วย ดังนั้นจึงเป็นสิ่งสำคัญอย่างยิ่งในการตรวจสอบว่าภาพสไลด์แบบเล่นอัตโนมัติไม่ใช่แหล่งที่มาของการเปลี่ยนเลย์เอาต์

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนเลย์เอาต์ได้ที่หัวข้อแก้ไขข้อบกพร่องการเปลี่ยนเลย์เอาต์

ใช้เทคโนโลยีสมัยใหม่

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

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

ต่อไปนี้คือแหล่งข้อมูลเกี่ยวกับการใช้ scroll-snap ที่อาจเป็นประโยชน์กับคุณ

• การสร้างคอมโพเนนต์เรื่องราว (web.dev)
• การจัดรูปแบบเว็บรุ่นใหม่: Scroll Snap (web.dev)
• ภาพสไลด์สำหรับ CSS เท่านั้น (เทคนิค CSS)
• วิธีสร้างภาพสไลด์ CSS เท่านั้น (เทคนิค CSS)

เพิ่มประสิทธิภาพเนื้อหาภาพสไลด์

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

การวัดประสิทธิภาพ

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

การวัด LCP สำหรับภาพสไลด์

ประเด็นสำคัญในการทำความเข้าใจวิธีการคำนวณ LCP สำหรับภาพสไลด์มีดังนี้

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

การเปลี่ยนแปลงการคํานวณ LCP สําหรับภาพสไลด์ใน Chrome 88

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

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

การเปลี่ยนแปลงเกณฑ์ใน Chrome 121

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

ข้อควรพิจารณาอื่นๆ

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

แนวทางปฏิบัติแนะนำสำหรับการไปยังส่วนต่างๆ

มีตัวควบคุมการไปยังส่วนต่างๆ ที่โดดเด่น

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

ระบุความคืบหน้าของการนำทาง

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

รองรับท่าทางสัมผัสบนอุปกรณ์เคลื่อนที่

บนอุปกรณ์เคลื่อนที่ ท่าทางสัมผัสด้วยการเลื่อนควรได้รับการรองรับเพิ่มเติมจากการควบคุมการนำทางแบบดั้งเดิม (เช่น ปุ่มบนหน้าจอ)

ระบุเส้นทางการนำทางอื่น

เนื่องจากผู้ใช้ส่วนใหญ่มักไม่มีส่วนร่วมกับเนื้อหาภาพสไลด์ทั้งหมด เนื้อหาที่ภาพสไลด์ลิงก์จึงควรเข้าถึงได้จากเส้นทางการนำทางอื่นๆ

แนวทางปฏิบัติแนะนำเกี่ยวกับความอ่านง่าย

ไม่ใช้การเล่นอัตโนมัติ

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

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

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

แยกข้อความและรูปภาพออกจากกัน

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

ใช้ชื่อที่กระชับ

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

แนวทางปฏิบัติแนะนำเกี่ยวกับผลิตภัณฑ์

ภาพสไลด์ทำงานได้ดีในกรณีที่ใช้พื้นที่แนวตั้งเพิ่มเติมเพื่อแสดงเนื้อหาเพิ่มเติมไม่ได้ ภาพสไลด์ในหน้าผลิตภัณฑ์ มักจะเป็นตัวอย่างที่ดีของกรณีการใช้งานนี้

อย่างไรก็ตาม อาจมีการใช้ภาพสไลด์อย่างมีประสิทธิภาพไม่ได้เสมอไป

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

ทดสอบสมมติฐานของคุณ

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

มีความเกี่ยวข้อง

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