HTML

En février 2023, j'écrivais ceci :

Par ailleurs, je m'interroge sur l'impact du paradigme Tailwind CSS (utility CSS) concernant l'empreinte mémoire des pages.
J'ai le sentiment que la profusion d'attributs class="..." va probablement augmenter considérablement la taille des pages.
#JaimeraisUnJour prendre le temps de mesurer cet aspect.

source

Cette question continue de me trotter dans la tête et mon intuition a évolué au fil du temps. J'ai maintenant l'intuition qu'une compression Brotli fonctionnerait efficacement avec le code Tailwind CSS.

Ce matin j'ai enfin pris le temps de faire des mesures.

J'ai choisi d'effectuer mes mesures sur le site de Blast qui est un site de contenu implémenté en Tailwind CSS.

Voici les mesures que j'ai effectuées :

• Home page https://www.blast-info.fr
  • Taille mémoire brute (non compressée) de la page complète sans dépendances : 453 Ko
  • Taille mémoire du HTML du body, récupéré avec l'inspecteur Firefox via "copier l'intérieur du HTML" : 178Ko
  • En supprimant tous les attributs class="...", je passe à 145Ko, soit une empreinte brute des attributs class de 33Ko (environ 18% du body)
  • Taille mémoire du texte seul : 5ko (2%)
  • Taille du body compressé Brotli : 25Ko
  • Taille du body sans attributs class="..." compressé Brotli : 23Ko, soit 2Ko pour les attributs classe (environ 8%)
• Page intérieure https://www.blast-info.fr/articles/2025/macron-bayrou-vers-un-jour-sans-fin-I0AwyT5KTf6_0ywKmLShVQ
  • Taille mémoire brute (non compressée) de la page complète sans dépendances : 404 Ko
  • Taille mémoire brute du HTML du body, récupéré avec l'inspecteur Firefox via "copier l'intérieur du HTML" : 281ko
  • En supprimant tous les attributs class="...", je passe à 251Ko, soit une empreinte brute des attributs class de 30Ko (environ 10% du body)
  • Taille mémoire du texte seul : 34ko (environ 12%)
  • Taille du body compressé Brotli : 43Ko
  • Taille du body sans attributs class="..." compressé Brotli : 40Ko, soit 3Ko pour les attributs classe (environ 6%)

Une fois compressé, la partie Tailwind CSS représente 2Ko à 3Ko par page. Il faut noter que ces valeurs constituent probablement une estimation haute, car un site utilisant le paradigme CSS traditionnel emploie généralement aussi des class="…" dans ses pages HTML.

Mon constat : je pense que le surcout de Tailwind CSS sur la taille des pages d'un site de contenu demeure négligeable après compression.

Une autre question que je me pose : quel est l'impact de Tailwind CSS sur l'utilisation mémoire du navigateur ?

Un collègue m'a partagé le projet Marker (https://github.com/VikParuchuri/marker) :

Marker converts documents to markdown, JSON, and HTML quickly and accurately.

• Converts PDF, image, PPTX, DOCX, XLSX, HTML, EPUB files in all languages
• Formats tables, forms, equations, inline math, links, references, and code blocks
• Extracts and saves images
• Removes headers/footers/other artifacts
• Extensible with your own formatting and logic
• Optionally boost accuracy with LLMs
• Works on GPU, CPU, or MPS

source

Voici comment fonctionne Marker :

Marker is a pipeline of deep learning models:

• Extract text, OCR if necessary (heuristics, surya)
• Detect page layout and find reading order (surya)
• Clean and format each block (heuristics, texify, surya)
• Optionally use an LLM to improve quality
• Combine blocks and postprocess complete text

source

Dans l'article "Dependency management fatigue, or why I forever ditched React for Go+HTMX+Templ" (from), #JaiDécouvert :

• templ, qui permet de générer du code HTML SSR avec Golang en utilisant une syntax proche de JSX ;
• Datastar :

Datastar brings the functionality provided by libraries like Alpine.js (frontend reactivity) and htmx (backend reactivity) together, into one cohesive solution.

from

Cela me donne envie d'essayer ces technologies 🙂.