1 puntos por GN⁺ 2024-09-08 | 1 comentarios | Compartir por WhatsApp

WebP: el formato de compresión para páginas web

Obstáculos

  • Se minimiza el HTML para mejorar la accesibilidad del sitio web y reducir el tiempo de carga de la página
  • GitHub Pages no admite compresión Brotli
  • gzip se usa por defecto, pero Brotli ofrece una mejor tasa de compresión

Una idea simple

  • Como GitHub Pages no admite Brotli, se consideró descomprimirlo del lado del cliente con JavaScript
  • Se puede descomprimir Brotli usando brotli-dec-wasm y tiny-brotli-dec-wasm

Segundo intento

  • La Compression Streams API admite los formatos gzip y DEFLATE, pero no admite Brotli
  • La biblioteca Zopfli puede comprimir gzip de forma más eficiente, pero aun así rinde peor que Brotli

Rompiendo las reglas

  • Se consideró usar compresión de imágenes para comprimir datos
  • PNG y GIF usan el algoritmo DEFLATE, pero WebP ofrece un mejor rendimiento

Ventajas de WebP

  • WebP usa una transformación predictiva similar a la de PNG, pero en lugar de DEFLATE usa un método desarrollado por Google
  • Ofrece una compresión más eficiente mediante el uso de varios árboles de Huffman
  • Usa una caché de colores para almacenar de forma eficiente los colores repetidos

Experimento

  • Se probó comprimir archivos HTML con el crate webp
  • Los resultados iniciales mostraron un tamaño 2 veces menor que con gzip

Optimización adicional

  • Se ajustó el tamaño de la imagen para obtener un mejor rendimiento de compresión
  • Se probaron varios métodos de compresión para encontrar el resultado óptimo

Benchmark

  • Se compararon gzip, bzip2, Brotli y WebP en distintos formatos de archivo
  • En la mayoría de los casos, WebP mostró un mejor rendimiento que gzip
  • Aunque rinde peor que Brotli, sigue ofreciendo una mejora significativa

Decodificación con JavaScript

  • Se explica cómo decodificar WebP usando la Canvas API
  • Se usa WebGL para eludir técnicas anti-fingerprinting

Ajustes finales

  • Para reducir el parpadeo al cargar la página, se mantuvieron con gzip los estilos y la parte superior
  • Se propone una solución temporal para conservar la posición de desplazamiento

Embebido

  • Se incrustó WebP directamente en JavaScript para reducir la latencia
  • Se usan data URLs en base64 para minimizar el tamaño

Ejemplo

  • Se ofrece un ejemplo real de una página web comprimida usando WebP
  • Se confirma que el tamaño de la página se reduce después de la compresión

Resumen de GN⁺

  • Este artículo explora varios métodos para mejorar el rendimiento de compresión de páginas web
  • El formato WebP ofrece mejor rendimiento que gzip, aunque rinde peor que Brotli
  • Explica cómo decodificar WebP del lado del cliente usando JavaScript y WebGL
  • Propone varias técnicas de optimización para reducir el tiempo de carga de la página
  • Otros proyectos con funciones similares incluyen Brotli y Zopfli

1 comentarios

 
GN⁺ 2024-09-08
Comentarios en Hacker News
  • Aunque el tamaño de una publicación larga se redujo de 92 KiB a 37 KiB, el aumento real en el tiempo de carga fue de apenas 0.001%

    • El tiempo de descompresión podría empeorar la experiencia del usuario
  • No se entiende por qué readPixels no recibe las protecciones contra fingerprinting

    • Existe una técnica para mantener el estilo de la parte superior de la página y comprimir en WebP solo el contenido por debajo del viewport
    • Si se desactiva WebGL en LibreWolf, la página no se recorta
  • zstd ya fue incorporado en Chrome y también debería implementarse en Safari

  • Quitar Google Fonts puede mejorar el tiempo de carga de la página

    • Como se cargan desde un servidor remoto, requieren handshakes adicionales
  • Al revisar el código fuente, se vio que falta un espacio en la declaración doctype

    • Actualmente está como <!doctypehtml>, pero debería corregirse a <!doctype html>
  • Una página HTML puede empaquetarse como un archivo ZIP autoextraíble

    • Se puede crear un archivo compatible con HTML, ZIP y PNG, incluyendo una imagen PNG
    • Por ejemplo, una imagen PNG puede mostrarse desde una página HTML
  • La página se rompe en el navegador de Sailfish OS

    • Hay un espacio en blanco largo después de los párrafos
    • El overhead de compresión HTML con gzip y brotli es insignificante comparado con la cantidad de JS/imágenes/video que usan los sitios web actuales
  • Aunque Brotli tiene un diccionario grande, muestra un rendimiento similar a gzip

    • Da curiosidad si el algoritmo de compresión es peor, o si la importancia del diccionario es menor de lo que se pensaba
  • La razón por la que Brotli no se usa en la CompressionStream API es que aumentaría mucho el tamaño del navegador

    • Es posible que el diccionario de compresión sea más grande porque contiene las representaciones más eficientes precalculadas