WebP: รูปแบบการบีบอัดเว็บเพจ

 (purplesyringa.moe)
1 คะแนน โดย GN⁺ 2024-09-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นี่คือการทดลองลดปริมาณข้อมูลที่ส่ง เมื่อ GitHub Pages ไม่รองรับ Brotli โดยเข้ารหัส HTML เป็นภาพ WebP แบบไม่สูญเสียข้อมูล แล้วกู้คืนด้วยตัวถอดรหัสภาพของเบราว์เซอร์และ JavaScript
  • ตัวถอดรหัส Brotli แบบ WASM มีต้นทุนเพิ่ม 71 KiB~200 KB และ Compression Streams API รองรับแค่ gzip, deflate, deflate-raw จึงยากจะใช้เป็น ทางเลี่ยงสำหรับการถอดรหัส Brotli
  • VP8L ซึ่งเป็น WebP แบบไม่สูญเสียข้อมูล สามารถให้ผลลัพธ์ที่เล็กกว่า gzip ได้แม้กับข้อมูลลักษณะข้อความ ด้วย predictive transform, การใช้ Huffman tree ซ้ำตามบล็อก 16x16, และ color cache
  • HTML ทดสอบขนาด 439,478 ไบต์ลดลงเหลือ gzip 94,683 ไบต์ และ WebP 43,182 ไบต์ แม้จะใหญ่กว่า Brotli 37 KiB แต่เล็กกว่า gzip ประมาณ 2.2 เท่า
  • ด้วยปัญหา noise ป้องกัน fingerprinting ของ Canvas 2D, การเปลี่ยนแปลงของ WebGL readPixels, หน้าจอว่างช่วงแรก และการกู้คืนตำแหน่งสกรอลล์ วิธีนี้จึงใกล้เคียงกับ แฮ็กที่เผยข้อจำกัดของเบราว์เซอร์ มากกว่าการนำไปใช้จริง

ปัญหาที่ GitHub Pages ใช้ Brotli ไม่ได้

  • เมื่อต้องการลดเวลาโหลดหน้าเว็บ การบีบอัด HTTP ให้ผลมากกว่า HTML minify
  • HTTP รองรับ gzip และ Brotli ผ่านเฮดเดอร์ Content-Encoding
    • gzip มีต้นทุนต่ำ จึงมักเปิดใช้เป็นค่าเริ่มต้น
    • Brotli โดยทั่วไปมีอัตราบีบอัดดีกว่า gzip แต่ช้ากว่ามาก
  • GitHub Pages ไม่รองรับ Brotli ทำให้บทความที่ยาวที่สุดของไซต์อย่าง Recovering garbled Bitcoin addresses จากที่อาจมีขนาด 37 KiB หากใช้ Brotli กลายเป็น 92 KiB เมื่อใช้ gzip
  • ความต่างนี้ทำให้เวลาโหลดเพิ่มขึ้นโดยไม่จำเป็นถึง 2.5 เท่า

ทางเลือกแรกที่คิดถึงและจุดที่ติดขัด

  • หาก GitHub รองรับการอัปโหลดและให้บริการไฟล์ Brotli ที่บีบอัดไว้ล่วงหน้า ก็เลี่ยงปัญหาได้ แต่ไม่มีฟีเจอร์แบบนั้น
  • วิธีคลายการบีบอัดโดยตรงฝั่งไคลเอนต์ด้วย JavaScript ให้ประโยชน์ลดลงเพราะขนาดของตัวถอดรหัส WASM
    • brotli-dec-wasm มีขนาดประมาณ 200 KB
    • tiny-brotli-dec-wasm มีขนาด 71 KiB
    • สิ่งที่ต้องเปรียบเทียบจึงกลายเป็น gzip 92 KiB กับเนื้อหา Brotli 37 KiB + 71 KiB ทำให้ข้อได้เปรียบหายไป
  • ใน HTTP stack ของเบราว์เซอร์มีตัวถอดรหัส Brotli อยู่ แต่ DecompressionStream ของ Compression Streams API รับเฉพาะ gzip, deflate, deflate-raw
  • แม้จะบีบอัด gzip ล่วงหน้าด้วย Zopfli ก็ยังมีขนาด 86 KiB ซึ่งยังใหญ่กว่า Brotli

ใช้ฟอร์แมตภาพเหมือนคอนเทนเนอร์บีบอัด

  • เบราว์เซอร์ถอดรหัสภาพได้อยู่แล้ว ดังนั้นหากใส่ข้อมูลลงในพิกเซลของภาพ แล้วอ่านกลับด้วย Canvas API ก็ไม่ต้องใส่ลอจิกคลายการบีบอัดใหม่
  • GIF กระจายข้อมูลตามลำดับ row-major แล้วใช้ LZW แต่ DEFLATE ของ gzip ถูกออกแบบมาเพื่อแทนที่ LZW อยู่แล้ว จึงคาดหวังประโยชน์ได้ยาก
  • PNG ใช้ DEFLATE แต่ก่อนบีบอัดจะใช้ predictive transform กับผลต่างระหว่างพิกเซลข้างเคียง ไม่ใช่พิกเซลดิบ
    • ตัวอย่าง: บีบอัด [a, b-a, c-b, d-c] แทน [a, b, c, d]
    • ยิ่งผลต่างระหว่างค่าที่ทำนายกับค่าจริงน้อย ก็ยิ่งเป็นประโยชน์ต่อการบีบอัด Huffman
  • แกนหลักของการทดลองคือการนำ VP8L ซึ่งเป็น WebP แบบไม่สูญเสียข้อมูล มาใช้สำหรับบีบอัดข้อมูลไบต์ทั่วไป

VP8L ต่างจาก gzip อย่างไร

  • WebP มีทั้งแบบสูญเสียข้อมูลและไม่สูญเสียข้อมูล โดยที่นี่กล่าวถึงเฉพาะ VP8L ซึ่งเป็นฟอร์แมตไม่สูญเสียข้อมูล
  • VP8L ใช้ predictive transform เหมือน PNG แต่ใช้วิธีคล้าย DEFLATE ที่ Google สร้างขึ้น แทน DEFLATE
  • DEFLATE สามารถแบ่งไฟล์เป็นหลายชิ้น และให้แต่ละชิ้นมี Huffman tree ที่เหมาะกับชิ้นนั้นได้
    • หาก JavaScript, SVG และมาร์กอัปปะปนกันใน HTML เดียวกัน tree ที่ต่างกันอาจให้ผลดีกว่า
  • VP8L กำหนดตาราง Huffman tree ที่ใหญ่ตามต้องการได้ และแต่ละ บล็อกพิกเซล 16x16 สามารถใช้ tree ต่างกันได้
    • ในกรณีที่มี JavaScript ตามด้วย CSS แล้วกลับมาเป็น JavaScript อีก DEFLATE อาจต้องเข้ารหัส tree ที่คล้ายกันซ้ำหลายครั้ง
    • VP8L ใช้ tree ซ้ำได้ จึงเปลี่ยน tree ได้บ่อยกว่าและถูกกว่า
  • color cache ของ VP8L สามารถแทนค่าด้วยรูปแบบสั้น ๆ เช่นให้คัดลอกพิกเซลล่าสุดที่มีคุณสมบัติบางอย่าง

การทดลองบีบอัด WebP ครั้งแรก

  • ไฟล์ทดสอบคือ HTML ของ Recovering garbled Bitcoin addresses
    • ขนาดต้นฉบับ: 439,478 ไบต์
    • gzip --best: 94,683 ไบต์
  • ใช้ crate webp ของ Rust แปลงไบต์เป็นภาพ RGB grayscale แล้วบีบอัดเป็น WebP แบบไม่สูญเสียข้อมูล
  • เหตุผลที่ใช้ grayscale คือ transform subtract green ของ WebP
    • ใน grayscale หากนำช่อง G ไปลบออกจาก R/B ช่อง R/B ก็แทบจะกลายเป็น 0
    • WebP เข้ารหัสสามช่องด้วย Huffman tree แยกกัน ดังนั้นช่องค่าคงที่จึงใช้พื้นที่ใกล้เคียง O(1)
  • ตอนแรกตั้งใจทำเป็นภาพ 1xN แต่ WebP รองรับสูงสุดเพียง 16383x16383 จึงเกิดข้อผิดพลาด VP8_ENC_ERROR_BAD_DIMENSION
  • เมื่อปรับเป็นรูปแบบ 16383xN ผลลัพธ์ได้ 45,604 ไบต์ เล็กกว่า gzip 2 เท่า และยังเล็กกว่า bzip2 49,764 ไบต์ด้วย

การปรับแต่งเฉพาะ WebP

  • หากใช้ลำดับ row-major กับภาพที่กว้าง ไบต์ที่อยู่ไกลกันในอินพุตจะถูกปะปนกันในบล็อก 16x16
  • เมื่อเปลี่ยนรูปร่างภาพเป็นแบบสูงและแคบ 27x16383 ผลการบีบอัดลดลงเหลือ 43,232 ไบต์
  • เปรียบเทียบการตั้งค่าประสิทธิภาพการบีบอัดของ cwebp คือ method ตั้งแต่ 0~6
    • method 0: 48,902
    • method 1: 43,546
    • method 2: 43,442
    • method 3: 43,292
    • method 4: 43,232
    • method 5: 43,182
    • method 6: 43,182
  • เลือก method 5 เพราะได้ขนาดเท่ากับ method 6 แต่เร็วกว่า
  • ในสภาพนี้ WebP เล็กกว่า gzip 2.2 เท่า และใหญ่กว่า Brotli 1.2 เท่า

เบนช์มาร์กหลายไฟล์

  • ชุดเปรียบเทียบคือ snappy testdata, Canterbury Corpus และ Large Corpus และไฟล์ SVG 2 ไฟล์
  • ฟอร์แมตที่เปรียบเทียบคือ gzip --best, brotli --best, bzip2 --best และสคริปต์บีบอัด WebP
  • WebP แทบจะดีกว่า gzip เสมอ ยกเว้นไฟล์ขนาดเล็กมากอย่าง grammar.lsp, xargs.1 และบางกรณี
  • ข้อยกเว้นคือ kennedy.xls และ paper-100k.pdf
    • paper-100k.pdf มีข้อมูลที่ถูกบีบอัดอยู่หลัง XML ขนาด 19 KB ทำให้แทบจะเป็นการวัดข้อมูลขนาดเล็ก
    • kennedy.xls มีประสิทธิภาพเทียบกับ Brotli/bzip2 ที่แปลกเช่นกัน และอาจเป็นไฟล์ที่คอมเพรสเซอร์จัดการยากเพราะมีข้อมูลต่างชนิดกันจำนวนมากอยู่ใกล้กัน
  • WebP โดยรวมแย่กว่า bzip2 เล็กน้อย แต่บางกรณีก็ทำได้ดีกว่า
  • WebP แย่กว่า Brotli เสมอ ยกเว้นกรณีอย่าง fireworks.jpeg ที่แทบเป็น blob สุ่มสม่ำเสมอ
  • สำหรับข้อมูล plain-text ขนาดใหญ่ มีการปรับปรุงที่วัดได้เมื่อเทียบกับ gzip
    • ไฟล์ SVG ก็มีการปรับปรุงเช่นกัน
    • ใน html_x_4 WebP มีอัตราบีบอัด 3.3% ซึ่งแย่กว่า Brotli 2.8% แต่ดีกว่า gzip 13% มาก

กู้คืนด้วย JavaScript

  • การถอดรหัส WebP เองสามารถทำได้ด้วย fetch, createImageBitmap, OffscreenCanvas, getImageData, TextDecoder
  • โครงสร้างคือใช้ช่อง R ของพิกเซลเป็นไบต์ HTML ต้นฉบับ ถอดรหัสเป็น UTF-8 แล้วใส่ลงใน document.documentElement.innerHTML
  • Canvas API ถูกใช้ทำ fingerprinting บ่อย เบราว์เซอร์บางตัวจึงเพิ่ม noise ลงในผลลัพธ์ของ getImageData
    • ใน strict tracking protection ของ Firefox พิกเซลน้อยกว่า 1% อาจได้รับผลกระทบ
    • ใน HTML noise นี้จะปรากฏเหมือนตัวสะกดผิด
  • หากใช้ readPixels ของ WebGL ในตอนนั้นจะทำงานได้โดยไม่มี noise
    • WebGL รองรับเท็กซ์เจอร์ได้อย่างเสถียรถึง 2048x2048 เท่านั้น จึงต้องปรับข้อจำกัดด้านขนาดใหม่
    • โค้ดกู้คืนนี้มีขนาดประมาณ 550 ไบต์หลัง minify
  • รวม WebP และโค้ดแล้วได้ 44 KiB เทียบกับ gzip 92 KiB และ Brotli 37 KiB
  • หลังวันที่ 15 เมษายน 2026 Firefox เพิ่ม anti-fingerprinting ให้กับ readPixels ด้วย ทำให้วิธีนี้ไม่ทำงานเหมือนเดิมอีกต่อไป

ปัญหาหน้าจอกะพริบและการสกรอลล์

  • await ถูกประมวลผลแบบอิง promise ดังนั้นก่อนที่การดาวน์โหลด WebP จะเสร็จ เบราว์เซอร์จะถือว่าการรันสคริปต์จบแล้ว
  • DOM ยังว่างอยู่ ผู้ใช้จึงเห็น หน้าจอขาวว่าง ชั่วครู่
  • วิธีบรรเทาคือคงสไตล์และส่วนบนของหน้าประมาณ 8 KiB ไว้ใน HTML แบบ gzip แล้วบีบอัดเฉพาะเนื้อหาใต้ viewport ด้วย WebP
  • การกู้คืนตำแหน่งสกรอลล์ตอนรีเฟรชก็เป็นปัญหาเช่นกัน
    • เช่น หากรีเฟรชที่ตำแหน่ง Y = 5000px แต่ความสูงหน้าเป็น 0px ตำแหน่งจะถูกรีเซ็ต
    • การเพิ่ม div ชั่วคราวขนาดใหญ่มากช่วยได้
  • ต้องกำหนดค่าให้ document.documentElement.innerHTML แทน document.write เพื่ออัปเดตโดยไม่แทนที่เอกสารปัจจุบันด้วยเอกสารใหม่

ใส่ WebP ลงใน JavaScript โดยตรง

  • เพื่อลด latency เพิ่มอีกเล็กน้อย สามารถฝัง WebP ลงใน JavaScript โดยตรงได้
  • วิธีที่ง่ายที่สุดคือ base64 data URL
  • base64 ทำให้ขนาดเดิมเพิ่มเป็น 1.33 เท่า แต่ gzip แทบจะชดเชยส่วนเพิ่มนี้ได้ทั้งหมด
    • เมื่อแปลง compressed.webp เป็น base64 จะได้ 57,576 ไบต์
    • เมื่อนำไปบีบอัดด้วย gzip --best จะได้ 43,519 ไบต์
  • blob ที่ถูกบีบอัดอย่าง WebP เป็นข้อมูลสุ่มที่เกือบสม่ำเสมอ และ Huffman tree ของ gzip ทำงานกับผลลัพธ์การแปลง 8 บิตเป็น 6 บิตของ base64 แทบเหมือนการแปลงกลับ
  • อาจใช้ Unicode และ UTF-16 ได้เช่นกัน แต่ base64 ยังเป็นวิธีแก้แรกที่เพียงพอ

การนำไปใช้จริงและสถานะภายหลัง

  • ณ เวลาที่เขียนบทความ หน้าเว็บนี้เองถูกบีบอัดด้วย WebP ตั้งแต่ส่วน “Fool me twice” เป็นต้นไป หากไม่ใช่เบราว์เซอร์เก่าหรือสภาพแวดล้อมที่ปิด JavaScript
  • ภาพ WebP ของหน้าในโค้ดจริงสูงและแคบในแนวตั้ง แต่มีตัวอย่าง WebP แบบสี่เหลี่ยมจัตุรัสที่ดูสวยงามให้ด้วย
  • ส่วนบนและล่างที่สว่างในภาพคือข้อความและโค้ด พื้นที่ลายแฮตช์ราว 1/5 ของภาพคือไดอะแกรม และพื้นที่มืดส่วนใหญ่คือข้อความในไดอะแกรม
  • ปริมาณที่ลดได้จริงมีจำกัด
    • หน้า gzip เดิม: 88 KiB
    • หน้า gzip หลังใช้ WebP: 83 KiB
    • คาดการณ์ Brotli: 69 KiB
  • หลังวันที่ 15 เมษายน 2026 เพื่อไม่ให้ผู้เข้าชมผ่าน Firefox เห็นเนื้อหาที่เสียหาย ปัจจุบันจึงเปลี่ยนกลับเป็นหน้าแบบไม่บีบอัด
  • โค้ด Rust, corpus และไฟล์อื่น ๆ เผยแพร่บน GitHub

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

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

 
GN⁺ 2024-09-08
ความคิดเห็นจาก Hacker News

  • ถ้าไม่นับเรื่อง latency ก็คงใช่ แต่ในทางปฏิบัติดูเหมือนเวลาโหลดจะเพิ่มขึ้นราว ๆ 0.001% เท่านั้น
    ขนาดที่เพิ่มขึ้นไม่มีนัยสำคัญเมื่อเทียบกับ round-trip latency และเวลาที่ใช้คลายการบีบอัดอาจมากกว่าเวลาที่ประหยัดได้จากการส่งข้อมูลน้อยลง 55KiB ด้วยซ้ำ
    แม้จะเป็นการทดลองที่น่าสนุก แต่ในกรณีนี้ประสบการณ์ผู้ใช้น่าจะแย่ลงมากกว่า และความเร็วแทบจะเท่าเดิม แต่ความเข้ากันได้ลดลงเท่านั้น

    • ถ้ามองแค่การปรับเวลาโหลดให้เหมาะสมและสมมติว่าความเร็วข้อมูลของทุกคนเหมือนกันก็พูดถูก แต่บ่อยครั้งผมไม่อยากให้ผู้เขียนเว็บไซต์หรือแอปตัดสินใจเรื่อง การแลกระหว่างความเร็ว/ปริมาณข้อมูล แทนผมง่ายเกินไป
      ปัญหาคือมีคนอย่างผู้เขียน TFA ที่พยายามลด 100KB ให้เหลือ 50KB แต่ก็มีที่ที่ส่งรูปภาพหลายสิบ MB มาให้ผมอย่างไม่แยแส ทั้งที่ผมแค่อยากดูเวลาเปิดร้านอาหารผ่านดาต้าโรมมิง
      ความตระหนักเรื่องทรัพยากรมีอยู่จริง แต่น่าเสียดายที่กระจายตัวไม่สม่ำเสมออย่างมาก
    • ไม่ใช่แค่ปัญหาเวลาคลายการบีบอัด ต้องดาวน์โหลดทั้งหมดก่อนถึงจะคลายการบีบอัดได้ แต่เบราว์เซอร์สามารถ คลายการบีบอัดและเรนเดอร์ HTML ที่สตรีมมาจากเซิร์ฟเวอร์ได้ทันที
      ถ้าการเชื่อมต่อหลุดก็เสียทั้งหมด และแม้แต่การอ่านเฉพาะส่วนที่ดาวน์โหลดมาแล้วก็ทำไม่ได้
      บนการเชื่อมต่อทั่วไปความต่างไม่มีนัยสำคัญ และบนการเชื่อมต่อที่ช้ามากหรือไม่เสถียรจน 50KB มีความสำคัญ วิธีนี้จะแย่กว่าอย่างชัดเจน เป็นการทดลองที่น่าสนุก แต่ไม่อยากให้เอาไปใช้กับไซต์จริง
    • ถ้าไม่ได้อยู่ในแคช ก็มีไฟล์ Symbols-2048-em%20Nerd%20Font%20Complete.woff2 ขนาด 850K อยู่ ซึ่งแทบจะกลบความต่างนั้นหมด
    • ความต่างของขนาดระดับนั้นใหญ่พอจะมีผลต่อจำนวน round trip ที่ต้องใช้ ด้วยค่า initial congestion window แบบสมัยใหม่ที่สมเหตุสมผล น่าจะลดได้ประมาณ 1 round trip
      คงไม่ต่าง 2.5 เท่า แต่ก็ไม่ใช่ 0.001% แน่
    • ถ้าประหยัดได้น้อยกว่า TCP receive window หนึ่งอัน ก็ไม่น่าจะทำให้ latency ต่างกัน
      บนเครือข่ายที่มีการสูญหายของแพ็กเก็ตอาจมีความต่างได้ แต่ก็ไม่แน่ใจ

  • ไม่เข้าใจว่าทำไม readPixels ถึงไม่ถูกจัดเป็นเป้าหมายของการป้องกัน fingerprinting สำหรับผมไม่เป็นไร เพราะคงไม่มีใครโปรย typo ที่แทบมองไม่เห็นไปทั่วทั้งหน้า
    พอเห็นส่วนที่บอกว่าใน HTML ที่ gzip แล้วจะเหลือไว้แค่สไตล์กับราว 8KiB ตอนบนของหน้า ส่วนเนื้อหาใต้ viewport จะถูกบีบอัดเป็น WebP ก็อธิบายได้ว่าทำไมบทความถึงถูกตัดกลางคันหลังประโยคแบบสุ่มแล้วตามด้วยหน้าว่าง
    ผมใช้ LibreWolf อยู่จึงปิด WebGL ไว้ และเกมเว็บสุ่ม ๆ ที่ต้องใช้ WebGL ก็ใช้ Chromium แทน พอเปิด WebGL บทความก็ทำงานได้ดี และพูดตามตรง เทคนิคนี้ค่อนข้างเรียบร้อยดี

    • ถ้ามันใช้ไม่ได้ในเว็บเบราว์เซอร์สมัยใหม่ทั้งหมด แม้แต่ตอนเปิดการป้องกัน fingerprinting และไม่มี fallback สำหรับเบราว์เซอร์เก่า ก็ยากจะเรียกว่าเรียบร้อย
      WWW ควรเข้าถึงได้ทั่วไปโดยเริ่มจาก HTML ธรรมดา แล้วค่อย ๆ ยกระดับแบบ progressive enhancement

  • ในเว็บเบราว์เซอร์ การใช้ Brotli โดยตรง ก็เป็นไปได้ แต่แน่นอนว่ามีข้อจำกัด
    ผมคิดว่างานที่ส่งเข้าประกวด JS1024 ปี 2022 [1] เป็นการสาธิตแนวคิดนี้ครั้งแรก และยังมีโค้ด proof of concept สำหรับการบีบอัดแบบ arbitrary ด้วย น่าเสียดายที่มันไม่เหมาะกับเป้าหมายเดิมคือ size coding
    ข้อจำกัดหลักคือแทบจะถูกจำกัดอยู่กับอักขระ ASCII และด้วยเหตุผลที่ชัดเจน มันไวต่อ rendering stack มาก ตอนนี้ดูเหมือนจะใช้กับ Firefox ไม่ได้

    [1] https://js1024.fun/demos/2022/18/readme

    [2] https://gist.github.com/lifthrasiir/1c7f9c5a421ad39c1af19a9c...

    • แก่นสำคัญในการเข้าใจแนวทางนี้คือส่วนต่อไปนี้ ซึ่งไม่จำเป็นต้องลงลึกว่าจริง ๆ แล้วยัดมันเข้าไปได้อย่างไร
      ทำได้แค่ใช้ รูปแบบไฟล์ฟอนต์ WOFF2 ซึ่ง Brotli ถูกออกแบบมาแต่เดิม แต่ถ้าจะใช้ประโยชน์จากมันก็ต้องสร้างไฟล์ฟอนต์ทั้งไฟล์
      เบราว์เซอร์ยุคใหม่มักทำความสะอาดฟอนต์ด้วย OpenType Sanitizer (OTS) เพราะการเอาไฟล์ฟอนต์ที่ไม่น่าเชื่อถือใส่ระบบโดยตรงนั้นอันตรายมาก ดังนั้นจึงต้องสร้างไฟล์ WOFF2 ที่ปกติพอให้ OTS ยอมรับ แต่ในขณะเดียวกันก็มีลำดับไบต์ที่ต้องการอยู่ข้างในและสามารถดึงออกมาได้
      ไอเดียที่หลังจากล้มเหลวมาหลายครั้งแล้วไปลงตัวที่ความกว้างของ glyph หรือ advance ซึ่งถูกเข้ารหัสเป็นลำดับจำนวนเต็มมีเครื่องหมาย 2 ไบต์แทบไม่มีข้อจำกัดนั้นยอดเยี่ยมมาก
    • ขอแก้ไขว่าใน Firefox ก็ยังใช้ได้อยู่ แค่ผมลืมไปว่าใน Firefox อัตราซูมต้องเป็น 100% พอดี
    • เทคนิคนี้น่าทึ่งจริง ๆ และเจ๋งกว่าบทความของผมมาก ขอคารวะ

  • ฝั่ง Chromium ขวางไว้มานาน แต่ zstd ก็กำลังเข้ามาในเว็บแล้ว ตอนนี้ในที่สุดก็เข้า Chrome แล้ว เหลือแค่ Safari ตามมาให้ทัน

    • อยากย้ายไปใช้ Zstandard ทั้งหมด แต่ในกรณีเฉพาะนี้ เท่าที่ผมรู้ เมื่อใช้หน่วยความจำของตัวคลายการบีบอัดเท่ากัน Brotli กับ Zstandard แทบจะใกล้เคียงกัน
    • อย่างน้อยก็ดูเหมือนจะอยู่ในรายการสิ่งที่ต้องทำ: https://webkit.org/standards-positions/#position-168

  • กำลังทำ Batch Compress(https://batchcompress.com/en) อยู่ และไม่นานหลังจากที่เพิ่งเพิ่ม การรองรับ WebP ก็เปลี่ยนให้เป็นค่าเริ่มต้น
    เท่าที่ผมรู้ เครื่องมือนี้ก็ทำ JPEG ได้เล็กที่สุดในบรรดาเครื่องมือบีบอัดบนเว็บอยู่แล้ว แต่ WebP ออกมาเหลือแค่ราว 50% ของขนาด JPEG เท่านั้น การเปลี่ยนให้เป็นค่าเริ่มต้นไม่นานหลังเพิ่มการรองรับจึงเป็นการตัดสินใจที่ง่ายมาก
    เว็บไซต์มีผู้ใช้ค่อนข้างมาก เลยคิดว่าหลังเปลี่ยน WebP เป็นค่าเริ่มต้นน่าจะมีเสียงบ่นอยู่บ้าง แต่ตอนนี้ผ่านมาประมาณหนึ่งเดือนแล้ว มีคำถามหรือข้อร้องเรียนเกี่ยวกับ WebP แค่เรื่องเดียวเท่านั้น
    ตอนนี้ดูเหมือนว่าเครื่องมือและเบราว์เซอร์แทบทั้งหมดรองรับ WebP แล้ว ช่วงหลังเห็นแค่เว็บไซต์หนึ่งที่จัดการอัปโหลดภาพ WebP ได้ไม่ถูกต้องจนติดอยู่ในขั้นตอนถัดไป นอกนั้นทุกวันนี้แทบทั้งหมดรองรับได้ดี

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

  • ระหว่างดูซอร์ส เห็นว่า การประกาศ doctype ขาดช่องว่างไป รูปแบบปัจจุบันไม่ถูกต้องและควรมีช่องว่าง

  • ผมเคยใช้ทริกนี้มาก่อน น่าแปลกที่จำไม่ได้ว่าใช้กับอะไร แต่คงแค่อยากดูว่าทำได้ไหม และเคยทิ้งคอมเมนต์ไว้ตรงนี้ด้วย: https://gist.github.com/gasman/2560551?permalink_comment_id=...
    ยังเจอต้นแบบเก่า ๆ ด้วย ซึ่งดูเหมือนจะเป็นแค่การทดสอบ: https://retr0.id/stuff/bee_movie.webp.html

    • หน้านั้นทำให้ ส่วนขยายท่าทางเมาส์ ของผมพัง
      เดี๋ยวนี้สิ่งพวกนั้นเหมือนการฉีดสคริปต์มากกว่า และเรียกว่าส่วนขยายไม่ใช่แอดออนแล้ว แต่ไม่ว่าอย่างไร แนวทางที่ตอนแรกส่ง “ขยะ” ไป แล้วต่อท้าย JS เพื่อส่งกลับเข้าไปในหน้าก็น่าสนใจ
      คนบ้าความปลอดภัยในตัวผมสงสัยว่าจะทำให้โจมตีได้หรือไม่ เมื่อมีข้อมูลที่ผู้ใช้ป้อนเข้ามาอย่างฟอร์มคอมเมนต์
      อาจเป็นไปได้ไหมที่ใครสักคนจะหาลำดับไบต์มาใส่ในคอมเมนต์ แล้วหลังบีบอัดมันไปอยู่ก่อนสคริปต์ของผมและกลายเป็นแท็ก script ที่ถูกเรียกใช้งาน
    • จากประสบการณ์ของผม WebP ไม่เหมาะกับกรณีทั่วไปที่เทคนิคนี้มีประโยชน์จริง ๆ นั่นคือ ข้อมูลต่ำกว่า 10KB
      เพราะสิ่งที่ WebP lossless เพิ่มให้ PNG ส่วนใหญ่เป็นเรื่องการทำโมเดล ไม่ใช่การเข้ารหัส และการบีบอัดข้อความแบบนี้จะใช้เฉพาะส่วนการเข้ารหัสของ WebP เท่านั้น

  • ถ้าเอา Google Fonts ออก เวลาโหลดหน้าก็น่าจะดีขึ้นเล็กน้อย เพราะโหลดจากเซิร์ฟเวอร์ระยะไกลและต้องมีการแฮนด์เชกเพิ่มเติม

    • แต่ถ้ามีเว็บไซต์อื่น ๆ มากพอใช้ฟอนต์นั้นเหมือนกัน มันก็อาจมีอยู่ในเครื่องอยู่แล้ว

  • หน้านี้แสดงผลพังอย่างน้อยใน เบราว์เซอร์ Sailfish OS มีช่องว่างยาว ๆ หลังย่อหน้าต่อไปนี้
    “Alright, so we’re dealing with 92 KiB for gzip vs 37 + 71 KiB for Brotli. Umm…”
    ถึงอย่างนั้น โอเวอร์เฮดของการบีบอัด HTML ด้วย gzip และ Brotli ก็แทบไม่มีความหมายเมื่อเทียบกับปริมาณ JS, รูปภาพ และวิดีโอที่เว็บไซต์สมัยนี้ใช้

    • Orion, Safari, LibreWolf ก็เหมือนกัน นี่เป็นหน้าสำหรับ Chrome เท่านั้นหรือเปล่า?
    • Mull ก็เหมือนกัน

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

    • น่าขันที่แม้แต่ Slides ซึ่งเป็นผลิตภัณฑ์ของ Google ก็ยังไม่รองรับภาพ WebP
      แต่ถ้าการรองรับเพิ่มขึ้นก็คงโอเค การมีฟอร์แมตใหม่สักครั้งในรอบ 20 ปีก็พอรับได้
      ส่วน .webm หายไปได้เลย
    • การแปลงใช้เวลาแค่ 2 วินาที บน macOS มันอยู่ในเมนูคลิกขวาจริง ๆ และขนาดก็เล็กกว่า จึงไม่ใช่ปัญหาเท่าไร