Articles sur Performance web

router.refresh() paraît inoffensif. En Next.js 16, il peut relancer le prefetch de tous les liens visibles et créer une tempête de requêtes (et d’ISR writes).

Le vrai problème des queues, c’est quand un événement part en rafale et déclenche 200 jobs identiques. Laravel 13.6 ajoute un debounce natif : on voit comment l’utiliser proprement en prod.

TypeScript 7 promet un gros boost de perf grâce à tsgo. Mais ton repo vit surtout via ton IDE, ta CI et ton tooling : voilà comment tester sans tout casser.

Composer n’est pas « juste un install de dépendances ». En CI, c’est déjà un moteur d’exécution (VCS, plugins, scripts) : ces CVE côté Perforce sont le bon moment pour blinder.

Arrête de débattre à l’instinct : mesure l’écart “avec adblock” vs “sans” pour isoler la part pub dans tes Core Web Vitals, puis transforme ça en budget et garde-fous.

Tu peux empiler des workers jusqu’à ce que “ça passe”… ou dimensionner proprement ton throughput et arrêter de payer pour du hasard. Voilà la méthode terrain.

Tu upgrades Vite et @vitejs/plugin-react, et d’un coup tes plugins Babel ne tournent plus. Normal : le plugin React passe à oxc. Voilà comment brancher React Compiler 1.0 sans te battre.

Quand un feed XML fait plusieurs centaines de Mo, DOM et SimpleXML te mettent un OOM tôt ou tard. Voilà un pattern XMLReader + streaming qui tient en prod, avec insert en chunks et garde-fous.

MF 2.0 promet des micro-frontends plus portables (plus seulement webpack). La vraie question est : est-ce que ton produit peut encaisser la complexité qui va avec ?