Baseline : le secret pour livrer beaucoup moins de JavaScript

Baseline : le secret pour livrer beaucoup moins de JavaScript

Vous vous souvenez de l’époque bénie de jQuery ? On glissait un fichier de 90 Ko dans son projet et soudain, `$(document).ready()` rendait tout incroyablement fluide. Puis on est devenus plus malins, on a découpé nos bundles, et on a troqué jQuery contre React, Vue, et une armoire entière de micro-bibliothèques pour chaque petit besoin.

Mais voilà ce que je n’arrête pas de me surprendre à faire : installer une bibliothèque de formatage de dates de 20 Ko alors que le navigateur que je cible propose littéralement une API qui fait la même chose. Gratuitement. Sans requête réseau. Sans bump de version. Sans maintenance future.

C’est là que **Baseline** entre en jeu.

Si vous n’en avez pas encore entendu parler, Baseline est une initiative soutenue par le W3C qui nous offre une étiquette simple et universelle pour répondre à la question : « quand puis-je utiliser cette fonctionnalité sans risque ? » Elle répond à la question la plus pénible du développement web avec un seul mot : **aujourd’hui**. Et en vous aidant à identifier ce que la plateforme web sait déjà faire, Baseline peut réduire considérablement le JavaScript que vous livrez. Voyons comment.

C’est quoi, Baseline, vraiment ?

Baseline, c’est une compréhension commune de la compatibilité navigateurs entre tous les acteurs majeurs : Chrome, Edge, Firefox, Safari et Opera. Au lieu de consulter une matrice « ça marche dans 97 % des navigateurs », Baseline vous dit si une fonctionnalité est **disponible** (elle fonctionne dans les navigateurs actuels) ou **nouvellement disponible** (elle vient d’arriver dans les dernières versions). L’idée, c’est de supprimer le doute.

Pensez à Baseline comme à « caniuse, mais avec un verdict plus clair ». Quand une fonctionnalité devient Baseline, ça veut dire que tous les navigateurs de l’écosystème courant la prennent en charge. C’est votre feu vert.

Et le meilleur dans tout ça ? Baseline est intégré à des endroits que vous utilisez probablement déjà. Ouvrez les tableaux de compatibilité MDN, cherchez une fonctionnalité, et vous verrez un badge Baseline juste à côté. Ou allez voir [web.dev/baseline](https://web.dev/baseline) pour un tableau de bord de ce qui est prêt aujourd’hui.

Pourquoi c’est important pour la taille de votre bundle

L’écart entre « il vous faut une bibliothèque pour ça » et « le navigateur sait déjà le faire » ne cesse de se réduire. Chaque année, les navigateurs ajoutent des API qui exigeaient autrefois des polyfills, des bibliothèques utilitaires et des fonctions helper. Si vous livrez encore `moment-timezone` pour la gestion des fuseaux horaires ou `lodash` pour `_.debounce()`, vous payez pour quelque chose que la plateforme fournit déjà. En octets, et en complexité.

Voici trois exemples concrets où Baseline peut vous aider à couper du poids mort.

Scénario 1 : le formatage de dates sans la dépendance de 50 Ko

J’ai travaillé un jour sur un projet qui importait `date-fns` juste pour formater quelques dates dans un tableau de bord. L’appli entière était un tableau de bord statique. On livrait 16 Ko de fonctions de dates localisées pour afficher des chaînes comme « 9 août 2026 ».

Mais voici une petite expérience : ouvrez la console de votre navigateur et tapez :

```js
new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date())
```

C’est tout. **Pas d’import, pas de npm install, pas de version épinglée.** L’objet `Intl` est une fonctionnalité Baseline depuis des années. Il gère le formatage localisé, les fuseaux horaires, et même le temps relatif façon date-fns avec `Intl.RelativeTimeFormat`.

Vous voulez faire disparaître tout le bundle ? Faites correspondre vos fonctions date-fns à leurs équivalents natifs :

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (ou `new Date()`, avec précaution)
- `zonedTimeToUtc` → `Intl` avec l’option `timeZone`

Oui, il y a des cas limites. Mais pour 90 % des projets, l’API `Intl` native fait le travail. Et elle est disponible en Baseline, donc tous les navigateurs modernes la gèrent.

Scénario 2 : remplacer Lodash par le DOM

Je vois encore `lodash.debounce` dans certaines bases de code. Cinq kilo-octets pour forcer une fonction à attendre un peu avant de s’exécuter. Mais le navigateur a ça en natif :

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Et si vous êtes fainéant comme moi, un simple `setTimeout` dans un écouteur d’événements suffit dans la plupart des cas. Même chose pour `_.throttle`, `_.clamp`, `_.range` : tout ça se fait en quelques lignes de JavaScript vanilla.

Mais on peut aller plus loin. Vous avez déjà utilisé `_.forEach` ? Le prototype Array a `forEach`, `map`, `filter`, `reduce` — tout est Baseline. `_.get` pour accéder à des propriétés imbriquées en sécurité ? L’optional chaining est une fonctionnalité Baseline depuis 2020. `_.unique` ? C’est juste `Set`.

Le DOM lui-même est une mine d’or : `classList.toggle()` remplace `_.toggleClass`, `Element.matches()` remplace les sélecteurs de `_.is()`, et l’`IntersectionObserver` natif remplace des bibliothèques entières de scroll-spy. La prochaine fois que vous êtes sur le point d’ajouter une dépendance, demandez-vous : « Est-ce que c’est juste un joli wrapper autour de quelque chose que `document.querySelectorAll` me donne déjà ? »

Scénario 3 : les requêtes HTTP sans axios

Axios est une belle bibliothèque, mais en 2026, l’API `fetch` native est Baseline et couvre presque tous les cas d’usage. Le streaming ? `fetch` prend en charge `response.body.getReader()`. L’authentification ? Vous pouvez gérer les en-têtes, les credentials et les intercepteurs avec un petit wrapper. L’annulation ? C’est `AbortController`, également Baseline.

Pour un petit projet, j’ai remplacé axios par un helper de 20 lignes :

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

Pas de npm, pas de `node_modules` gonflés, pas d’avertissements de dépendances circulaires. Que du rapide, du natif, du fiable.

Comment auditer vos dépendances avec Baseline, concrètement

Vous êtes convaincu. Et maintenant ? Voici une méthode pratique à mettre en œuvre dès cet après-midi.

1. Lister les dépendances de runtime

Faites `npm ls --production` ou regardez simplement votre `package.json`. Repérez tout ce qui n’est pas votre framework ou une bibliothèque de gestion d’état. Ces petites bibliothèques utilitaires sont les cibles idéales.

2. Vérifier chacune d’elles avec Baseline

Pour chaque bibliothèque de votre liste, posez-vous deux questions :

- Quel problème est-ce que ça résout ?
- Est-ce que je peux le résoudre avec une API web disponible en Baseline ?

Cherchez la fonctionnalité sur MDN. Si vous voyez le badge vert « Baseline available », c’est bon. Si vous voyez « Nouvellement disponible » et que vous visez des navigateurs modernes, ça vaut le coup d’y réfléchir. Si c’est rouge « Limited », gardez la bibliothèque pour l’instant.

Astuce rapide : ouvrez les outils de développement dans Chrome, Safari ou Firefox et testez l’API directement. Si elle fonctionne sans drapeau, c’est bon signe.

3. Chercher dans le code les signes qui ne trompent pas

Faites un grep pour des motifs comme `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'` ou `from 'jquery'`. Ensuite, regardez à quelle fréquence ces fonctions sont vraiment utilisées. Parfois, on se rend compte qu’on utilise trois méthodes sur une bibliothèque qui en contient 200. Ça, c’est une opportunité en or.

4. Remplacer et comparer

Faites la migration une bibliothèque à la fois. Faites une PR séparée pour pouvoir mesurer le changement de taille du bundle. Utilisez le rapport de taille de votre outil de build ou vérifiez simplement la taille du fichier dans les devtools. Je recommande de passer Lighthouse avant et après. Voir le « JavaScript execution time » chuter, c’est une sensation magnifique.

Le côté humain de livrer moins de JavaScript

Pourquoi est-ce qu’on s’en préoccupe, au-delà de la satisfaction un peu fière d’avoir un bundle plus léger ? Parce que JavaScript est la ressource la plus coûteuse qu’on envoie aux navigateurs. Chaque octet doit être téléchargé, analysé, compilé et exécuté. Chaque API économisée, c’est une page qui se charge plus vite pour quelqu’un sur un Android pas cher avec une connexion 3G instable. Tout le monde n’a pas un MacBook Pro branché sur la fibre.

Livrer moins de JavaScript, c’est aussi moins de charge mentale pour vous, le développeur. Chaque dépendance est une faille de sécurité potentielle, un casse-tête de migration potentiel et une source potentielle de bugs bizarres quand son mainteneur décide de passer à autre chose. Les API natives sont maintenues par les éditeurs de navigateurs. Autrement dit, elles seront mises à jour, documentées et prises en charge pendant des années.

Et il y a un bénéfice plus profond : vous commencez à comprendre la plateforme web elle-même. Quand vous utilisez `Intl`, `URL`, `Promise`, `Map`, l’optional chaining et `fetch` directement, vous devenez un meilleur développeur web. Vous n’êtes plus seulement un consommateur d’abstractions, vous êtes un artisan qui connaît le grain du bois.

Des bémols ? Oui. Ne faites pas n’importe quoi.

Baseline n’est pas une baguette magique. Certaines API avancées sont encore trop récentes pour être disponibles en Baseline partout. Par exemple, l’API Popover ou l’API View Transitions sont « nouvellement disponibles », mais pas encore déployées dans tous les navigateurs. Si vous construisez un site public pour un large public, vous voudrez peut-être attendre ou prévoir un repli élégant.

Supprimer une bibliothèque ne veut pas toujours dire écrire moins de code. Parfois, il faut écrire un peu plus de JavaScript vanilla pour arriver au même comportement. Mais bon, quelques lignes de code en plus, c’est votre code, et c’est plus maintenable qu’une grosse bibliothèque utilitaire que vous ne comprenez pas entièrement.

Et enfin, ne devenez pas un ayatollah des API natives. Si une bibliothèque transforme votre productivité et vous facilite la vie, utilisez-la. Le but de Baseline n’est pas de vous faire honte parce que vous utilisez des bibliothèques sophistiquées. C’est de vous aider à faire des compromis éclairés. N’allez pas non plus installer `safe-password-generator` alors que `crypto.getRandomValues()` est disponible en Baseline depuis 2015.

Bonus : comment rester à jour avec Baseline

La plateforme web évolue vite. Pour rester au courant de ce qui devient disponible en Baseline, je fais deux choses :

1. Consulter le tableau de bord **Web Platform Features** sur [web.dev/baseline](https://web.dev/baseline) environ une fois par mois.
2. Lire la section **Actualités Baseline** de MDN, qui liste les fonctionnalités nouvellement disponibles chaque mois.

Vous pouvez aussi suivre le dépôt GitHub du groupe communautaire WebDX : [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). C’est là que la magie opère.

Questions fréquentes

Qu’est-ce que « disponible en Baseline » signifie exactement ?

Ça signifie qu’une fonctionnalité est prise en charge dans les versions actuelles et récentes de tous les navigateurs majeurs : Chrome, Edge, Firefox, Safari et Opera. Vous pouvez l’utiliser sans polyfill ni solution de repli pour ces navigateurs.

Baseline, c’est la même chose que caniuse.com ?

Non, mais c’est lié. Caniuse vous donne des tableaux de compatibilité détaillés, y compris pour les anciennes versions. Baseline résume ces données en une étiquette simple : « prêt ou pas prêt ». Il garantit aussi que l’information est contextuelle : ce n’est pas parce que ça marche dans Chrome 120 que ça marche dans Safari 12.

Et si je dois encore supporter un vieux navigateur comme IE11 ?

IE11 est mort, et avant même ça, c’était une exception. Baseline exclut explicitement les navigateurs obsolètes comme IE11. Si vous devez vraiment supporter des environnements aussi anciens, il faudra consulter les tableaux détaillés et peut-être inclure des polyfills pour les API choisies. Mais en 2026, on peut légitimement se demander pourquoi vous supportez encore IE11 : ce sont vos utilisateurs qui choisissent de rester sur une vieille technologie, et c’est vous qui en payez le prix.

Comment convaincre mon équipe d’utiliser Baseline ?

Montrez-leur les chiffres. Choisissez une dépendance, estimez le coût en taille de bundle et en maintenance, puis montrez le remplacement natif dans un prototype rapide. Je l’ai fait avec lodash dans un ancien boulot. Quand mon responsable a vu la diff — une bibliothèque de 5 Ko remplacée par deux lignes de JavaScript vanilla — il était convaincu. Et envoyez-leur aussi le lien vers cet article. 😉

En résumé

Baseline n’est pas qu’un outil de compatibilité de plus. C’est un changement de mentalité. Au lieu de vous demander « quelle bibliothèque devrais-je utiliser pour ça ? », vous commencez à vous demander « qu’est-ce que le navigateur sait déjà faire pour moi ? ». Dès que vous faites ce basculement, le JavaScript superflu commence à fondre.

Vos utilisateurs ont un site plus rapide. Vous-même, dans le futur, héritez d’une base de code plus propre. Et le web devient un tout petit peu plus léger pour tout le monde.

Allez, ouvrez vos devtools, regardez le bundle de votre projet et voyez ce que vous pouvez couper. Votre navigateur a probablement déjà la réponse.