« 500 fois plus rapide » : cet algorithme pourrait régler le pire casse-tête des développeurs web

Cet algorithme pourrait bien préfigurer l’avenir de l’ingénierie des interfaces utilisateur. Si vous êtes développeur front-end– ou simplement intéressé par le sujet –, vous savez à quel point le texte sur le web peut rapidement devenir un casse-tête. Ce qui est d’autant plus ironique que le web est, en grande majorité… composé de texte.

Mais ces contraintes pourraient appartenir bientôt au passé. L’ingénieur logiciel Cheng Lou a annoncé, dans un message publié sur X le 28 mars 2026, avoir trouvé une solution. Concrètement, celui-ci a développé « un algorithme de mesure de texte rapide, précis et complet côté utilisateur », écrit en TypeScript pur et utilisable pour piloter la mise en page des pages web. Et ce, sans dépendre du CSS pour le layout du texte et en s’affranchissant des mesures DOM (et donc du reflow).

Pourquoi le texte sur une page web est-il un vrai casse-tête ?

Avant toute chose, il faut comprendre pourquoi le texte est un véritable casse-tête sur le web. Un « caractère » n’est pas toujours une lettre simple : il y a les emojis, les drapeaux, les variantes de couleur de peau, les ligatures, les écritures cursives… Tout cela fait que la largeur visuelle ne correspond pas simplement au nombre de caractères.

Ensuite, les langues n’ont pas les mêmes règles : en français ou en anglais, on coupe aux espaces ; en chinois ou en japonais, il n’y a pas d’espace entre les mots. D’autres langues ont des règles de coupure très spécifiques, sans parler des écritures qui peuvent se lire de droite à gauche ou verticalement.

Le navigateur applique en plus un moteur typographique sophistiqué (polices, kerning, césure, sens d’écriture mélangés) pour transformer du texte brut en glyphes affichés à l’écran. Résultat : savoir combien de place va prendre un paragraphe est un problème difficile, que seuls les moteurs internes des navigateurs résolvent correctement.

Pour afficher une page, le navigateur transforme le HTML en DOM, un arbre en mémoire où chaque balise et chaque bout de texte devient un objet. Ensuite, il applique les règles CSS (police, taille, marges, largeur de colonne, etc.) pour calculer comment le texte se casse en lignes dans chaque bloc, leur largeur et hauteur, ainsi que la position de chaque élément sur la page.

Ce calcul s’appelle le « layout ». À chaque modification ou lorsqu’on interroge certaines propriétés, le navigateur peut être obligé de recalculer tout ou partie de ce layout : c’est le fameux « reflow ». Et celui-ci est coûteux. Si un site le déclenche trop souvent — par exemple pour mesurer en permanence des blocs de texte –, les performances chutent et l’interface devient moins fluide.

Pour un développeur, le besoin est simple : savoir à l’avance combien de place prendra un texte. Mais sur le web, cette question en apparence triviale est en réalité l’une des plus complexes à résoudre.

Jusqu’ici, il n’existait que deux approches :

• Laisser le navigateur faire, puis mesurer : on insère un élément dans le DOM, on laisse le moteur casser les lignes, puis on lit la taille — au risque de déclencher un reflow.
• Reproduire soi-même la logique de mise en page du texte, ce qui implique de gérer les langues, les coupures, les emojis… un travail extrêmement complexe.

Résultat : pour des interfaces avancées (colonnes éditoriales, texte autour de formes, viewers de documents, interfaces de chat sophistiquées), les développeurs accumulent des contournements DOM/CSS coûteux en performances — et souvent en créativité.

En quoi consiste ce nouvel algorithme ?

L’algorithme de Cheng Lou, regroupé dans sa bibliothèque Pretext, propose de reprendre la mise en page du texte côté JavaScript/TypeScript, au lieu de la laisser entièrement au navigateur.

Pour construire son moteur, le développeur a d’abord pris les principaux navigateurs comme référence : il a observé comment ces derniers cassent le texte, sur des milliers de combinaisons de contenus, de polices et de largeurs de colonnes.

Il a ensuite utilisé des IA de programmation (Claude Code, Codex) pour générer et affiner l’algorithme, en le confrontant en continu au comportement réel des navigateurs. Une approche presque expérimentale : plutôt que de reproduire théoriquement un moteur typographique, il s’agit ici d’en apprendre les règles en observant ses résultats.

Son outil fonctionne ensuite en deux temps. Il prépare d’abord le texte une fois pour toutes (découpage et mesure précise via un canvas), puis recalcule à la volée la manière dont ce texte se casse en lignes, en pur TypeScript, sans interroger le DOM.

Concrètement, Pretext ne demande presque jamais « combien mesure cette boîte ? » au navigateur : il mesure le texte via un canvas, corrige ponctuellement certains cas (notamment certains emojis), puis ne fait plus que des calculs pour déterminer la hauteur des paragraphes.

Le développeur évoque des performances pouvant aller jusqu’à « 500 fois plus rapides », tout en reconnaissant que la comparaison est biaisée. En réalité, Pretext ne fait pas la même chose que le moteur de layout du navigateur, qui calcule la mise en page. Il évite surtout les allers-retours coûteux avec ce dernier. Le gain ne vient donc pas d’un code intrinsèquement plus rapide, mais d’un changement complet d’approche. On ne demande plus au navigateur « combien mesure ce bloc de texte ? » — on le calcule directement, à partir de données déjà disponibles.

Une approche prometteuse

Cette approche ouvre la voie à des interfaces plus précises, plus performantes et plus créatives. Elle permet notamment de créer des bulles de chat qui épousent exactement la taille du message, même sur plusieurs lignes, sans bricolage CSS. Elle rend aussi crédible une mise en page multi-colonnes façon magazine, mais entièrement responsive et recalculée en direct. Elle permet même de faire de l’ASCII art avec des polices non monospace, puisque chaque caractère est mesuré précisément.

Plus largement, elle simplifie de nombreux cas réputés pénibles en CSS : zones de texte auto-dimensionnées, accordéons dynamiques, centrage vertical de texte multi-lignes ou rendu typographique dans un canvas.

« Le moteur est minuscule (quelques ko), conscient des particularités des navigateurs, et prend en charge toutes les langues nécessaires, y compris le coréen, l’arabe RTL (écriture de droite à gauche) et les emojis spécifiques à chaque plateforme », affirme Cheng Lou.

Reste une limite importante : imiter le comportement des navigateurs ne garantit pas une correspondance parfaite dans tous les cas. Les moteurs de rendu intègrent des années d’optimisation et gèrent des subtilités typographiques extrêmement complexes, qui évoluent en permanence.

De plus, sur le papier, Pretext ne remet pas en cause l’accessibilité dès lors que le texte reste rendu dans le DOM. En revanche, les usages les plus ambitieux — où tout est dessiné dans un canvas ou un moteur graphique maison — devront reconstruire une partie de l’accessibilité du web (sélection, lecture par synthèse vocale, navigation au clavier), un chantier loin d’être trivial.

Une bibliothèque comme Pretext devra donc faire ses preuves sur le long terme, notamment face aux différences entre plateformes, polices ou langues. Mais si l’approche tient, elle pourrait changer en profondeur la manière dont le web gère le texte — en redonnant aux développeurs la main sur un terrain longtemps dominé par les navigateurs. À noter que Pretext est disponible comme bibliothèque open source sur GitHub, et peut être intégré à un projet web via npm.

Toute l'actu tech en un clin d'œil

Ajoutez Numerama à votre écran d'accueil et restez connectés au futur !

Installer Numerama