YouTube embeds หนักเกินไป และแก้ไขได้

 (frontendmasters.com)
2 คะแนน โดย GN⁺ 2024-07-08 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • YouTube embed แบบพื้นฐาน `` แม้ใส่เพียงรายการเดียวในหน้าว่าง ก็ทำให้เกิด 32 requests และ ปริมาณข้อมูลที่ถ่ายโอน 1.3MB ซึ่งหนักเกินไปเมื่อเทียบกับ UI วิดีโอขนาดเล็ก
  • หากใส่วิดีโอหลายรายการ ทรัพยากรจะไม่ถูกแชร์กัน ทำให้น้ำหนักเพิ่มขึ้นแบบ เชิงเส้น โดยการวัดของ Zach Leatherman พบว่า 2 รายการเพิ่มเป็น 2.4MB และ 3 รายการเพิ่มเป็น 3.6MB
  • ฟีเจอร์ที่เห็นในตอนแรกมีเพียงภาพโปสเตอร์ ชื่อเรื่อง และปุ่มเล่นขนาดใหญ่ จึงสามารถสร้างประสบการณ์แบบเดียวกันให้เบาลงได้ด้วย Web Component อย่าง ``
  • lite-youtube-embed มีขนาดราว 100KB และแชร์ทรัพยากรระหว่าง embed หลายรายการได้ จึงช่วยปรับปรุงความเร็วและประสิทธิภาพโดยไม่สูญเสียฟีเจอร์
  • เนื่องจาก YouTube embed ถูกใช้งานอย่างแพร่หลาย การลดข้อมูลระดับเมกะไบต์ต่อหนึ่ง embed จึงเป็นการปรับแต่งที่มีผลจริง แม้แต่ต่อการใช้ไฟฟ้าและ การปล่อยคาร์บอน

ต้นทุนของ embed แบบพื้นฐาน ``

  • เมื่อเลือก Embed จากเมนูแชร์ของ YouTube จะได้ HTML ที่อิงกับ ``
  • โค้ดพื้นฐานไม่มี loading="lazy" ทำให้วิดีโอที่อยู่นอกหน้าจออาจถูกโหลดทันที
  • หาก YouTube เพิ่มเพียง lazy loading ให้กับ iframe พื้นฐาน ก็จะปรับปรุงประสิทธิภาพได้ทันที
  • หากต้องการทำให้ iframe เป็น responsive และคงอัตราส่วนเดิมไว้ สามารถกำหนด YouTube embed iframe โดยตรงด้วย CSS ได้
iframe[src^="https://www.youtube.com/embed/";] {
  inline-size: 100%;
  block-size: auto;
  aspect-ratio: 16 / 9;
}

ค่าที่วัดได้จริงและการเพิ่มขึ้นแบบเชิงเส้น

  • แม้ใส่ YouTube embed เพียงรายการเดียวในหน้าว่าง ต้นทุนการโหลดก็สูงอย่างชัดเจน

    • 32 requests

      • ถ่ายโอนข้อมูล 1.3MB
      • โหลด 2.76 วินาที บน WiFi ของผู้เขียน
      • Zach Leatherman บันทึกไว้ว่าเมื่อจำนวน embed เพิ่มขึ้น ทรัพยากรจะไม่ถูกแชร์กัน ทำให้น้ำหนักเพิ่มขึ้นแบบเชิงเส้น
      • embed 2 รายการ: 2.4MB
      • embed 3 รายการ: 3.6MB
      • ปัจจุบันดูเหมือนว่าขนาดจะเพิ่มขึ้นมากกว่าช่วงเวลาที่ Zach เคยตรวจสอบ

UI ที่ผู้ใช้เห็นในตอนแรกนั้นเรียบง่าย

  • องค์ประกอบที่ผู้ใช้เจอเป็นอย่างแรกใน YouTube embed มีจำกัด
    • ภาพโปสเตอร์ ของวิดีโอ
    • ชื่อเรื่อง ของวิดีโอ
    • ปุ่มเล่น ขนาดใหญ่ที่คลิกแล้วเล่นวิดีโอ
  • UI และพฤติกรรมระดับนี้สามารถทำได้โดยไม่ต้องโหลดทรัพยากรของ YouTube player ทั้งหมดตั้งแต่แรก
  • ข้อกล่าวอ้างว่า embed แบบเบาทำให้ engagement ลดลงนั้นตัดสินได้ยาก หากไม่มีการเปิดเผยวิธีการและข้อมูล
  • ในอดีตเคยมีกรณีที่วิศวกร YouTube ทดสอบหน้าวิดีโอที่เบากว่า แล้วเวลาโหลดเฉลี่ยกลับเพิ่มขึ้น
    • หน้าเว็บที่เบากว่าเข้าถึงผู้ใช้ที่มีอุปกรณ์ประสิทธิภาพต่ำและอินเทอร์เน็ตช้าได้มากขึ้น
    • การใช้งานของผู้ใช้ที่เพิ่งเข้าถึงได้ใหม่อาจทำให้ตัวชี้วัดเวลาโหลดเฉลี่ยดูช้าลง
    • หากดูแค่เวลาโหลดเฉลี่ย อาจพลาดการปรับปรุงความเร็วจริงในระดับผู้ใช้แต่ละคน

ทางเลือก: `` Web Component

  • lite-youtube-embed ที่สร้างโดย Paul Irish บุคคลด้าน performance ของ Google เป็น Web Component ที่จำลองประสบการณ์ embed พื้นฐานให้เบาลง
  • คำอธิบายโปรเจกต์ระบุว่าเรนเดอร์เหมือน embed จริงแต่เร็วขึ้นประมาณ 224 เท่า
  • ประสบการณ์ผู้ใช้แทบเหมือน YouTube embed พื้นฐาน
    • แสดงภาพโปสเตอร์
    • แสดงชื่อเรื่อง
    • แสดงปุ่มเล่นขนาดใหญ่
    • เล่นวิดีโอเมื่อคลิก
  • ความแตกต่างอยู่ที่การใช้ทรัพยากรและวิธีแชร์
    • YouTube embed พื้นฐาน: ประมาณ 1.3MB
    • ``: ประมาณ 100KB
    • แชร์ทรัพยากรระหว่าง embed หลายรายการได้
    • ได้ความเร็ว ประสิทธิภาพ และการคุ้มครองความเป็นส่วนตัวพื้นฐานโดยไม่สูญเสียฟีเจอร์

วิธีใช้งานและการติดตั้งที่เกี่ยวข้อง

  • เป็นวิธีที่ลงทะเบียน Web Component ด้วย JavaScript แล้วใช้องค์ประกอบ ``
  • ใช้ได้ทั้งการติดตั้งผ่าน npm, คัดลอกโดยตรง หรือใช้ลิงก์ CDN
import "https://esm.sh/lite-youtube-embed";;
  • วิธีที่ README แนะนำคือวาง HTML ไว้ก่อน แล้วโหลดสคริปต์แบบ async เพื่อใช้ progressive enhancement
  • สามารถใส่ background-image ไว้ใน HTML เพื่อให้แสดงผลถูกต้องแม้ก่อน JavaScript จะโหลดเสร็จ

  [Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)

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

2 ความคิดเห็น

 
GN⁺ 2024-07-08
ความคิดเห็นบน Hacker News

  • บนแพลตฟอร์มฟอรัมชุมชน มีการตรวจจับ YouTube embed แล้วแทนที่ด้วยภาพตัวอย่างแบบพร็อกซีที่ยังไม่โหลดจนกว่าจะคลิก
    แค่มีคนหนึ่งในเธรดแชร์วิดีโอ YouTube ไม่ได้หมายความว่าทุกคนที่เปิดหน้านั้นจำเป็นต้องดาวน์โหลด JavaScript 1MB+ และถูก Google ติดตาม IP ไปด้วย

    • ผม/ฉันดูแลเว็บแบบ infinite scroll ที่ส่วนใหญ่เป็น embed ของ YouTube, SoundCloud และ Reddit ซึ่ง YouTube ต้องจัดการแบบนี้ถึงจะพอใช้งานได้
      ไม่ได้ใส่ใจเรื่องการติดตามมากนัก จึงใช้ภาพตัวอย่างที่ YouTube ให้มาโดยตรง
    • อยากรู้ว่ามีวิธีแก้คล้าย ๆ กันสำหรับ SoundCloud ไหม
      เพลเยอร์ของ SoundCloud ก็หนักมากเหมือนกัน
    • พอดีกำลังแก้ปัญหาเดียวกันอยู่ ถ้ามีทิปหรือเคสตัวอย่างของวิธีนี้ก็อยากทราบ
    • สงสัยว่าภาพตัวอย่างถูกแคชหรือพร็อกซีด้วยหรือเปล่า
      ถ้าทำ hotlink ภาพตัวอย่าง Google ก็ยังติดตามจากตรงนั้นได้อยู่ดี

  • ผู้เขียนบอกว่าไม่เชื่อหลักฐานที่ว่ารุ่นที่เบากว่าจะทำให้ engagement ลดลง แต่ผม/ฉันคิดว่าเป็นไปได้มากพอสมควร
    ในเดโมของโปรเจกต์ lite-youtube-embed ที่ถูกแนะนำ มีทั้งเพลเยอร์แบบเบาและเพลเยอร์ปกติ โดยเวอร์ชันเบาใช้เวลานานกว่าอย่างเห็นได้ชัดกว่าจะเริ่มเล่นวิดีโอ
    ทุก ๆ 1 มิลลิวินาทีที่เวลาโหลดเพิ่มขึ้น engagement ก็ลดลง และในกรณีนี้ดูเหมือนต่างกันเป็นหลายร้อยมิลลิวินาทีขึ้นไป
    https://paulirish.github.io/lite-youtube-embed/

    • มีแนวโน้มเป็นแบบนั้นสูง แต่ก็ต้องพิจารณาด้วยว่าการทำให้วิดีโอเริ่มเร็วขึ้นคุ้มกับต้นทุนที่ทำให้หน้าเว็บที่ฝังวิดีโอนั้นเองช้าลงหรือไม่
      ตรรกะที่ว่า ทุกมิลลิวินาทีมีความสำคัญ ก็ใช้กับหน้าเว็บได้เช่นกัน ถ้าผู้ใช้ออกจากหน้าไป ก็ไปไม่ถึงวิดีโออยู่ดี
      อีกอย่าง การที่ผู้ใช้ไม่อยากดูวิดีโอก็อาจเป็นเรื่องโอเค ส่วนตัวถ้าหน้าเว็บมีสรุป ก็ชอบเพราะเลี่ยงการดูวิดีโอได้
      การปรับโฉม YouTube บนเดสก์ท็อปก็ไม่พอใจเหมือนกัน เพราะใช้พื้นที่หน้าจอไปโปรโมตวิดีโออื่นมากกว่าวิดีโอที่ตั้งใจจะมาดูจริง ๆ อยากให้มีสิ่งรบกวนน้อยลง
    • ในช่วงเวลาที่พบไม่บ่อยนักที่ตั้งใจจะดูวิดีโอที่ฝังไว้จริง ๆ การรอ ไม่กี่ร้อยมิลลิวินาที ดีกว่าการโหลดเพลเยอร์ฝังทั้งหมดทุกครั้งที่เข้าหน้า ทั้งที่อาจไม่ได้ดูเลยมาก
      ถ้าเปรียบกับไฟจราจร ผม/ฉันอยากให้สัญญาณที่กำลังเข้าใกล้เป็นไฟเขียว มากกว่าทุกสัญญาณเป็นไฟแดงสั้น ๆ
    • คำว่า “ทุก ๆ 1 มิลลิวินาทีที่เวลาโหลดเพิ่มขึ้น engagement จะลดลง” ฟังดูใกล้เคียงความเชื่อแบบยุค 90
      ดูจากพฤติกรรมจริงของบริษัทใหญ่ ๆ ก็ชัดว่าพวกเขาไม่ได้สนใจเรื่องนั้น และถ้ามันไม่สำคัญสำหรับพวกเขา ก็ไม่มีเหตุผลที่เราต้องไปช่วยปรับแต่งแทน
      ในกรณีการใช้งานนี้ไม่ใช่ปัญหาใหญ่ แต่ในสแต็กส่วนอื่น ๆ ยังควรใส่ใจประสิทธิภาพ
    • เพลเยอร์ YouTube สมัยก่อนโหลดและบัฟเฟอร์วิดีโอทั้งคลิปไว้ ทำให้สะดวกเพราะถ้าดูซ้ำก็ไม่ต้องดาวน์โหลดใหม่
      ไม่รู้ว่าถอยหลังมาเป็นแบบนี้ได้อย่างไร และดูเหมือน Google กำลังค่อย ๆ ทำให้สิ่งที่เคยทำงานดีอยู่แล้วแย่ลง
    • มีความต่างอยู่บ้าง แต่ดูไม่ใหญ่มาก และถ้าถึง 100ms ก็คงน่าแปลกใจ
      อาจขึ้นอยู่กับสภาพแวดล้อม: Firefox, แล็ปท็อป i7-1185G7 อายุราว 2 ปี, Windows 11, Edge โหมด 32 บิตที่ยังอัปเดตอยู่เรื่อย ๆ และไม่ได้รีบูตมาหลายสัปดาห์
      สิ่งที่ทำให้รู้สึกว่าช้าส่วนใหญ่คือไอคอนโหลดแบบหมุน เหมือนกำลังโฆษณาตัวเองว่าช้า
      ดีเลย์หลังคลิกจนถึงเริ่มเล่นย่อมมีผลอยู่บ้าง แต่ถ้าจะวัดให้ถูกต้องจริง ๆ คงต้องเป็นองค์กรระดับ YouTube

  • เกี่ยวกับข่าวลือที่ว่า embed ที่เบากว่าจะลด engagement และ lite-youtube-embed ที่ถูกเสนอ ผู้ใช้อาจมองว่าเพลเยอร์ที่หน้าตาหรือพฤติกรรมต่างไปแม้เพียงเล็กน้อยเป็นสิ่งแปลกหน้าและไม่น่าไว้ใจ
    lite-youtube-embed ในเดโมแม้จะแสดงชื่อเรื่อง แต่ไม่มีลิงก์ไปยังหน้า YouTube จริง จึงให้ความรู้สึกเป็นปรปักษ์เหมือนพยายามกันไม่ให้ไปถึง “คอนเทนต์” ต้นฉบับ
    แน่นอนว่าฟีเจอร์นั้นเพิ่มได้ไม่ยาก แต่มันเผยให้เห็นปัญหาที่ใหญ่กว่า
    ผม/ฉันแทบไม่เล่นวิดีโอที่ฝังไว้ แต่ถ้าจะเล่น ก็แค่ประสบการณ์ YouTube ปกติก็พอแล้ว ถ้าถูกห่อด้วยเลเยอร์แปลก ๆ อีกชั้น ก็ยิ่งลดโอกาสที่จะคลิก
    คำว่า “ไม่มีอะไรต้องเสียสละ” ในบทความนี้เป็นตัวอย่างของนักพัฒนาที่เข้าใจผิดว่าตัวเองรู้ว่าผู้ใช้ใช้งานซอฟต์แวร์อย่างไร ทั้งที่จริง ๆ แล้วเป็นเพียงการเดาเสมอ
    หวังว่าจะมีวิดีโอน้อยลง การพึ่งพา Google ในทุกที่และก้อน JavaScript ลดลง เพื่อเว็บที่ดีกว่า อยากให้เลิกฝังวิดีโอ YouTube ไปทุกหนแห่ง
    https://paulirish.github.io/lite-youtube-embed/

    • แม้ใน UI embed ทางการของ YouTube ปุ่ม Watch on YouTube ก็ยังไม่เด่นพอ ทำให้ต้องกดเล่นก่อนเสมอ แล้วหยุดชั่วคราว จากนั้นค่อยกดปุ่ม YouTube มุมขวาล่าง
      ตอนนี้รู้แล้วก็อยากให้เพลเยอร์แบบเบาเหล่านี้มีปุ่มนั้นด้วย ถึงอย่างไร implementation นี้ก็ไม่ได้ปิดทางง่าย ๆ ในการเอาลิงก์ไปเสียทั้งหมด
    • lite-youtube-embed ยังไม่มีปุ่ม บันทึกลงดูภายหลัง ซึ่งเป็นฟีเจอร์ที่ใช้บ่อย
      ถ้าเล่นวิดีโอก็เข้าถึงได้ แต่นั่นขัดกับวัตถุประสงค์ ไม่ได้อยากเล่นวิดีโอ และก็ไม่อยากรอให้โหลดแล้วค่อยหยุดชั่วคราวเพื่อกดปุ่มบันทึก

  • ตอนนี้ก็เหลือแค่ทำให้บล็อกเกอร์ทั้งหลาย เลิกใช้ GitHub Gist embed ให้ได้
    Hugo และน่าจะรวมถึง static site generator อื่น ๆ รองรับโค้ดสั้น ๆ พร้อม syntax highlighting อยู่แล้วโดยค่าเริ่มต้น ส่วนเว็บที่ไดนามิกกว่านี้ก็ใช้ highlight.js เพื่อตัดการพึ่งพาบริการบุคคลที่สามได้
    การใช้ iframe หนัก ๆ กับโค้ดสั้น ๆ นี่แปลกมากจริง ๆ
    https://gohugo.io/content-management/syntax-highlighting/
    https://highlightjs.org

    • ผมว่าก็ปล่อยให้คนทำสิ่งที่อยากทำบนเว็บของตัวเองไปเถอะ
      ถึงผมจะไม่ชอบ แต่การ “บังคับ” ให้เขาเปลี่ยนเว็บให้ตรงกับรสนิยมของผมมันไม่สมเหตุสมผล
    • ตอนทำงานที่ Automattic ผมเคยพบว่า อีโมจิรูปหัวใจ ของ Gist ถูกเสิร์ฟจาก WordPress ไม่ใช่ GitHub
      มันถูกแก้ภายในไม่กี่สัปดาห์ แต่ผมแปลกใจที่สภาพนั้นค้างอยู่มาหลายปี

  • ถ้าในหน้าเว็บสามารถใช้ Content Security Policy ได้ ก็อาจบล็อกโฆษณาเพื่อลดน้ำหนักรวมของ embed และปรับปรุงประสบการณ์ผู้ใช้ได้
    ข้อมูลที่เกี่ยวข้อง: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

    • ไม่ควรใส่ unsafe-inline ลงใน Content-Security-Policy แบบไม่คิดให้ดี
      เพราะมันจะปิดการป้องกันการโจมตีแบบ injection ของ CSP ไปเลย ถ้าจำเป็นจริง ๆ ยังมีวิธีที่ปลอดภัยกว่าสำหรับอนุญาต inline script
      https://content-security-policy.com/

  • เรื่องที่ว่า “embed ที่เบากว่าทำให้ engagement ลดลง” ดูเหมือนจะขาดส่วนสำคัญไป
    โดยปกติถ้าเวลาโหลดเร็วขึ้น engagement ก็ควรดีขึ้น แต่ถ้า embed ที่เบาลงทำให้ engagement ลดลง ก็แปลว่ามีฟีเจอร์หรือพฤติกรรมบางอย่างถูกสละไป
    แต่บทความนี้บอกว่า ไม่ได้สละอะไรเลย แปลว่าในเรื่องนี้ต้องมีบางอย่างหายไป

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

  • ทางแก้ฝั่งผู้ใช้สำหรับผู้ใช้ uBlock คือใช้ฟิลเตอร์ click2load ได้
    แต่ Chrome กำลังย้ายไป Manifest V3 จึงอาจไม่ทำงาน ลองดูฟิลเตอร์ของ yokoffing/filterlists ได้
    https://raw.githubusercontent.com/yokoffing/filterlists/main...
    เขาเป็นผู้ทำ Betterfox และยังมีฟิลเตอร์มีประโยชน์อื่น ๆ บน GitHub ด้วย

    • Click2load เป็นการปรับปรุงที่ดี แต่ embed ก็ยังไม่ค่อยดีอยู่ดี
      สิ่งที่ผมอยากได้คือแค่ลิงก์ธรรมดา ๆ เลยเคยทำ userscript สั้น ๆ ที่เปลี่ยน YouTube iframe ในหน้าเว็บให้เป็นลิงก์
      สำหรับการทำแบบง่าย ๆ มันทำงานได้ดีจนน่าประหลาดใจ โดยหา iframe ของ youtube.com/embed และ youtube-nocookie.com/embed แล้วเปลี่ยนเป็นลิงก์ watch?v= พร้อมคง timestamp ไว้ได้ และถ้าต้องการก็แนบรูป thumbnail ได้ด้วย

  • ตรงที่บอกว่า “ยิ่งจำนวน embed เพิ่ม น้ำหนักก็เพิ่มแบบเชิงเส้น สองอันคือ 2.4MB สามอันคือ 3.6MB” ฟังดูแปลก
    สงสัยว่าทำไม resource เหล่านี้ไม่ถูกดึงจาก cache ถ้าทั้งหมดโหลดจาก www.youtube.com ก็น่าจะใช้ resource ที่ cache ไว้ได้ตาม same-origin policy ไม่ใช่หรือ

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

  • สมัยก่อนผมเคยทำส่วนขยาย Firefox ที่เปลี่ยน YouTube embed ทั้งหมดเป็น thumbnail แล้วเมื่อคลิกก็เปิด YouTube
    เดิมทีทำเพราะมือถือไม่มี Flash แต่ Flash embed พบได้ทั่วไป ต่อมาจึงขยายให้จัดการ iframe embed ด้วย
    ในกรณีส่วนใหญ่ การเปิดเป็นเว็บไซต์หรือแอป YouTube เต็มรูปแบบให้ประสบการณ์ผู้ใช้ดีกว่าหน้าต่าง embed เล็ก ๆ
    ตอนนั้นแม้จะเขียนให้เข้ากับ API ส่วนขยายระดับสูงชุดใหม่แล้ว แต่การรองรับข้ามเวอร์ชันของเบราว์เซอร์ก็ไม่ได้ต่อเนื่องอย่างที่คาด เลยหงุดหงิดและไม่ได้ย้ายไป WebExtension พออ่านบทความนี้แล้วก็อยากพอร์ตใหม่อีกครั้ง