1 poin oleh GN⁺ 2024-09-08 | 1 komentar | Bagikan ke WhatsApp

WebP: format kompresi halaman web

Hambatan

  • HTML diminalkan untuk meningkatkan aksesibilitas situs web dan mengurangi waktu muat halaman
  • GitHub Pages tidak mendukung kompresi Brotli
  • gzip digunakan secara default, tetapi Brotli memberikan rasio kompresi yang lebih baik

Ide sederhana

  • Karena GitHub Pages tidak mendukung Brotli, dipertimbangkan metode dekompresi di sisi klien menggunakan JavaScript
  • Dekompressi Brotli dimungkinkan dengan menggunakan brotli-dec-wasm dan tiny-brotli-dec-wasm

Percobaan kedua

  • Compression Streams API mendukung format gzip dan DEFLATE, tetapi tidak mendukung Brotli
  • Library Zopfli dapat mengompresi gzip dengan lebih efisien, tetapi performanya masih kalah dari Brotli

Melanggar hukum

  • Dipertimbangkan metode mengompresi data dengan memanfaatkan kompresi gambar
  • PNG dan GIF menggunakan algoritme DEFLATE, tetapi WebP memberikan performa yang lebih baik

Kelebihan WebP

  • WebP menggunakan transformasi prediksi yang mirip dengan PNG, tetapi memakai metode yang dikembangkan Google alih-alih DEFLATE
  • Menyediakan kompresi yang lebih efisien dengan berbagai pohon Huffman
  • Menggunakan color cache untuk menyimpan warna yang berulang secara efisien

Eksperimen

  • Mencoba mengompresi file HTML menggunakan crate webp
  • Hasil awal menunjukkan ukuran 2 kali lebih kecil dibanding gzip

Optimasi tambahan

  • Ukuran gambar disesuaikan untuk mendapatkan performa kompresi yang lebih baik
  • Berbagai metode kompresi dicoba untuk menemukan hasil yang optimal

Benchmark

  • Membandingkan gzip, bzip2, Brotli, dan WebP untuk berbagai format file
  • Dalam sebagian besar kasus, WebP menunjukkan performa yang lebih baik daripada gzip
  • Performanya kalah dari Brotli, tetapi tetap memberikan peningkatan yang berarti

Dekode dengan JavaScript

  • Menjelaskan cara mendekode WebP menggunakan Canvas API
  • Menggunakan WebGL untuk melewati teknik anti-fingerprinting

Penyesuaian akhir

  • Styling dan bagian atas halaman tetap menggunakan gzip untuk mengurangi kedipan saat halaman dimuat
  • Mengusulkan solusi sementara untuk mempertahankan posisi scroll

Embedding

  • WebP di-embed langsung ke JavaScript untuk mengurangi latensi
  • Menggunakan data URL base64 untuk meminimalkan ukuran

Contoh

  • Menyediakan contoh nyata kompresi menggunakan WebP pada halaman web
  • Menunjukkan bahwa ukuran halaman berkurang setelah dikompresi

Ringkasan GN⁺

  • Artikel ini mengeksplorasi berbagai metode untuk meningkatkan performa kompresi halaman web
  • Format WebP memberikan performa yang lebih baik daripada gzip, tetapi kalah dari Brotli
  • Menjelaskan cara mendekode WebP di sisi klien menggunakan JavaScript dan WebGL
  • Mengusulkan berbagai teknik optimasi untuk mengurangi waktu muat halaman
  • Proyek lain yang menyediakan fungsi serupa antara lain Brotli dan Zopfli

1 komentar

 
GN⁺ 2024-09-08
Komentar Hacker News
  • Meskipun ukuran postingan panjang berkurang dari 92 KiB menjadi 37 KiB, peningkatan waktu muat aktual hanya sebesar 0,001%

    • Pengalaman pengguna bisa menjadi lebih buruk karena waktu dekompresi
  • Sulit memahami mengapa readPixels tidak terkena fitur anti-fingerprinting

    • Ada teknik untuk mempertahankan styling di bagian atas halaman dan hanya mengompresi konten di bawah viewport dengan WebP
    • Jika WebGL dinonaktifkan di LibreWolf, halaman tidak terpotong
  • zstd telah diperkenalkan di Chrome, dan seharusnya juga diterapkan di Safari

  • Menghapus Google Fonts dapat memperbaiki waktu muat halaman

    • Karena dimuat dari server jarak jauh, diperlukan handshake tambahan
  • Setelah memeriksa source code, ternyata tidak ada spasi pada deklarasi doctype

    • Saat ini tertulis <!doctypehtml>, tetapi harus diperbaiki menjadi <!doctype html>
  • Halaman HTML dapat dipaketkan sebagai ZIP self-extracting

    • Bisa membuat file yang kompatibel dengan HTML, ZIP, dan PNG, termasuk gambar PNG
    • Misalnya, gambar PNG dapat ditampilkan di halaman HTML
  • Halaman rusak di browser Sailfish OS

    • Ada ruang kosong panjang setelah paragraf
    • Overhead kompresi HTML gzip dan brotli sangat kecil dibandingkan jumlah JS/gambar/video yang digunakan situs web saat ini
  • Meskipun Brotli memiliki dictionary besar, performanya mirip dengan gzip

    • Menarik apakah algoritma kompresinya lebih buruk, atau pentingnya dictionary ternyata tidak sebesar yang diperkirakan
  • Alasan Brotli tidak digunakan di CompressionStream API adalah karena hal itu akan sangat meningkatkan ukuran browser

    • Kemungkinan alasan dictionary kompresinya lebih besar adalah karena dictionary tersebut berisi representasi paling efisien yang telah dihitung sebelumnya