Articles sur Performance web

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 ?

Le pire incident, ce n’est pas une fuite de données. C’est ton app qui tombe en charge à cause d’une requête forgée. Cette CVE Next.js, c’est exactement ça.

Le lazy-loading est utile, mais « partout » c’est souvent un anti-pattern. Voilà les erreurs qui reviennent en audit et comment arrêter de plomber LCP, CLS et INP.

Tu optimises la DB, tu queues, tu chunk… et ton import Laravel rame toujours. Si tu valides des gros tableaux avec des wildcards, tu peux juste être en train de brûler du CPU en O(n²).

Laravel 13.3+ peut changer la connexion Redis utilisée par les sessions quand SESSION_CONNECTION est vide. Si tu as séparé « cache » et « default », ça peut te casser l’auth sans bruit.

Tu pushes, tu redeploy, tu forces un rebuild… et pourtant Vercel sert une version qui n’existe plus. Voilà comment je le prouve, puis comment je m’en sors sans tout casser.

Paralléliser en PHP, c’est cool… jusqu’au moment où ton “pool” se bloque tout seul. Voilà un pattern de process pool TrueAsync 0.6 qui tient en prod.

Oui, un client peut t’envoyer des timestamps en 2226. Et oui, ça peut suffire à flinguer tes requêtes “last 30 days”, tes caches et ta vue Analytics.

Entre .turbo et .next, tu peux te retrouver avec des dizaines de gigas “juste en dev”. Voilà comment comprendre ce qui s’accumule, quoi purger, et comment poser des limites sans flinguer les perfs.