WebP : le format de compression des pages web

 (purplesyringa.moe)
1 points par GN⁺ 2024-09-08 | 1 commentaires | Partager sur WhatsApp

WebP : le format de compression des pages web

Obstacles

  • Minimiser le HTML pour améliorer l’accessibilité du site web et réduire le temps de chargement des pages
  • GitHub Pages ne prend pas en charge la compression Brotli
  • gzip est utilisé par défaut, mais Brotli offre un meilleur taux de compression

Une idée simple

  • Comme GitHub Pages ne prend pas en charge Brotli, envisager une décompression côté client en JavaScript
  • brotli-dec-wasm et tiny-brotli-dec-wasm permettent de décompresser du Brotli

Deuxième tentative

  • L’API Compression Streams prend en charge les formats gzip et DEFLATE, mais pas Brotli
  • La bibliothèque Zopfli peut compresser gzip plus efficacement, mais reste moins performante que Brotli

Enfreindre les règles

  • Envisager une méthode consistant à compresser les données via la compression d’image
  • PNG et GIF utilisent l’algorithme DEFLATE, mais WebP offre de meilleures performances

Les avantages de WebP

  • WebP utilise une transformation prédictive similaire à PNG, mais avec une méthode développée par Google au lieu de DEFLATE
  • L’utilisation de différents arbres de Huffman permet une compression plus efficace
  • Un cache de couleurs permet de stocker efficacement les couleurs répétées

Expérience

  • Essai de compression d’un fichier HTML avec le crate webp
  • Les premiers résultats montrent une taille 2 fois plus petite que gzip

Optimisations supplémentaires

  • Redimensionner l’image pour obtenir de meilleures performances de compression
  • Tester différentes méthodes de compression afin de trouver le meilleur résultat

Benchmarks

  • Comparaison de gzip, bzip2, Brotli et WebP sur différents formats de fichiers
  • Dans la plupart des cas, WebP montre de meilleures performances que gzip
  • Les performances restent inférieures à Brotli, mais apportent tout de même une amélioration significative

Décodage en JavaScript

  • Explication d’une méthode de décodage de WebP avec l’API Canvas
  • Utilisation de WebGL pour contourner les techniques anti-fingerprint

Ajustements finaux

  • Conserver le style et la partie supérieure en gzip pour réduire le scintillement au chargement de la page
  • Proposition d’une solution temporaire pour conserver la position de défilement

Intégration

  • Intégrer directement WebP dans JavaScript pour réduire la latence
  • Utiliser une data URL en base64 pour minimiser la taille

Exemple

  • Fournir un exemple concret de page web compressée avec WebP
  • Vérifier la réduction de la taille de la page après compression

Résumé de GN⁺

  • Cet article explore différentes méthodes pour améliorer les performances de compression des pages web
  • Le format WebP offre de meilleures performances que gzip, mais reste moins performant que Brotli
  • Il explique comment décoder WebP côté client avec JavaScript et WebGL
  • Il propose différentes techniques d’optimisation pour réduire le temps de chargement des pages
  • Parmi les autres projets offrant des fonctionnalités similaires, on trouve Brotli et Zopfli

À lire aussi

1 commentaires

 
GN⁺ 2024-09-08
Commentaires Hacker News

  • Bien que la taille d’un long billet ait été réduite de 92 KiB à 37 KiB, l’augmentation réelle du temps de chargement n’est que de 0,001 %

    • Le temps de décompression peut dégrader davantage l’expérience utilisateur

  • Il est difficile de comprendre pourquoi readPixels n’est pas soumis aux protections anti-empreinte numérique

    • Il existe une technique qui conserve le style en haut de la page et compresse en WebP uniquement le contenu situé sous la fenêtre d’affichage
    • Si l’on désactive WebGL dans LibreWolf, la page n’est pas tronquée

  • zstd a été introduit dans Chrome et devrait aussi être adopté dans Safari

  • Supprimer Google Fonts peut améliorer le temps de chargement de la page

    • Comme elles sont chargées depuis un serveur distant, des handshakes supplémentaires sont nécessaires

  • En vérifiant le code source, on constate qu’il manque un espace dans la déclaration doctype

    • Actuellement, c’est <!doctypehtml>, mais il faut le corriger en <!doctype html>

  • Une page HTML peut être empaquetée comme une archive ZIP auto-extractible

    • Il est possible de créer un fichier compatible à la fois avec HTML, ZIP et PNG, y compris avec une image PNG
    • Par exemple, une image PNG peut être affichée dans une page HTML

  • La page s’affiche mal dans le navigateur de Sailfish OS

    • Il y a un long espace vide après les paragraphes
    • Le surcoût de la compression HTML en gzip et brotli est négligeable par rapport à la quantité de JS, d’images et de vidéos utilisée aujourd’hui sur les sites web

  • Brotli affiche des performances similaires à gzip malgré son grand dictionnaire

    • On peut se demander si l’algorithme de compression est moins bon, ou si l’importance du dictionnaire est plus faible qu’on ne le pense

  • Si Brotli n’est pas utilisé dans l’API CompressionStream, c’est parce qu’il augmenterait fortement la taille du navigateur

    • La taille plus importante du dictionnaire s’explique peut-être par le fait qu’il contient les représentations les plus efficaces précalculées