Cet article explore les performances de Symfony 7.4 sur FrankenPHP, une nouvelle approche de serveur PHP qui intègre l'interpréteur PHP directement dans Caddy, éliminant ainsi les surcharges de FastCGI et les configurations complexes de Nginx. L'auteur compare la latence et le débit de cette configuration avec celle de PHP-FPM, montrant une réduction significative du temps de réponse (de 45ms à 8ms) grâce au mode Worker de FrankenPHP, qui maintient l'application en mémoire après le premier démarrage. Le tutoriel guide à travers la mise en place de cette configuration avec Docker, en détaillant les étapes pour construire une image Docker optimisée et configurer le serveur Caddy. Il aborde également les avantages de cette architecture moderne, comme le support natif de HTTP/3 et HTTPS automatique.
L'auteur partage son expérience d'optimisation de traitement de données pour son blog, passant de plusieurs heures à quelques minutes. Il explique son architecture basée sur l'event sourcing pour analyser les visites, stockées dans une base de données et traitées par différents projecteurs. Face à un problème de performance lors de la reprocessus de 11 millions de lignes, il décrit son approche pour améliorer les performances, en commençant par établir une ligne de base de 30 événements par seconde.
L'article "Microservices Are Killing Your Performance (And Here's the Math)" explique comment les microservices, bien qu'ils promettent une meilleure scalabilité et maintenabilité, peuvent en réalité nuire aux performances. L'auteur compare les appels de fonctions en processus (monolithes) avec les appels HTTP entre microservices, montrant que ces derniers sont 1 000 à 5 000 fois plus lents. Un exemple concret de flux de checkout e-commerce illustre cette différence, avec une architecture microservices 15 % plus lente qu'une architecture monolithique. L'article aborde également le problème N+1 des services, où les dépendances entre services entraînent des temps d'exécution plus longs. Des benchmarks réels montrent que les microservices peuvent être jusqu'à 80 % plus lents dans certaines situations, malgré des conditions réseau parfaites et l'absence de pannes de service.
Cet article explique comment gérer et afficher des données massives dans une application Symfony en utilisant MongoDB. L'auteur, Andreas Braun, se base sur un dataset allemand de prix de carburant, qui change fréquemment et varie selon les villes. Le dataset comprend 78 Go de données de prix et près de 10 Go de données de stations, avec des fichiers organisés par année, mois et jour. L'article décrit comment inspecter les données, les importer dans MongoDB, et concevoir un schéma efficace pour travailler avec ce volume de données. La première partie se concentre sur l'inspection des données et la conception du schéma, tandis que la deuxième partie abordera la création d'une application Symfony pour afficher ces données.
Symfony UX Icons révolutionne la gestion des icônes dans Symfony en intégrant plus de 200 000 icônes SVG via Iconify, sans CDN, sans sprite et sans configuration complexe. Ce composant télécharge les icônes localement, les met en cache et les injecte directement dans le HTML, optimisant ainsi les performances et la maintenabilité. Avec une simple ligne de code Twig, vous pouvez utiliser des icônes de diverses collections comme Tabler, Lucide ou Material Design Icons. Installation via Composer et usage immédiat sans configuration supplémentaire.
Cet article explore comment enseigner aux agents IA à interpréter les données de performance, en s'appuyant sur une version modifiée de Chrome DevTools. Vinicius Dallacqua partage son expérience de création d'un assistant IA spécialisé dans la performance, en mettant l'accent sur la transformation des données brutes en informations exploitables. Il aborde les défis de la visualisation des données, l'amélioration continue de DevTools par l'équipe Chrome, et son projet PerfLab visant à réduire la barrière d'entrée pour les développeurs. L'objectif est d'automatiser l'extraction d'informations pertinentes à partir des fichiers de traces de performance.
L'article explore les risques liés à l'utilisation de contenus tiers (third parties) sur les sites web, notamment les points de défaillance uniques (SPOFs). Il explique comment ces dépendances externes peuvent ralentir un site bien optimisé et causer des interruptions de service, même pour les sites n'utilisant pas directement le fournisseur défaillant. L'auteur illustre ses propos avec des exemples concrets comme les boutons "J'aime" de Facebook en 2012, la fermeture de RawGit en 2018, et les récentes pannes de grands CDN. Il propose également des solutions pour tester et atténuer ces risques, en s'appuyant sur des données de l'HTTP Archive et du RUM Archive.
Ce guide pratique de Joan León, expert en performance web, explique comment utiliser Chrome DevTools pour détecter et résoudre les problèmes de performance sur un site web. L'auteur, consultant et co-fondateur de PerfReviews, partage sa méthodologie étape par étape, en se concentrant sur les fonctionnalités clés de DevTools pour l'analyse des performances. Il illustre son propos avec une analyse du site Zara, choisi parmi les sites à fort trafic organique lors du Black Friday 2025. Le guide met en lumière des outils comme le tri des ressources par taille dans l'onglet Réseau, l'identification des fichiers lourds et des images, et l'évaluation des stratégies de cache. L'objectif est de fournir des pistes pour améliorer l'expérience utilisateur en optimisant les performances.
L'article explique le mécanisme de BFCache (Back/Forward Cache) des navigateurs, qui permet de restaurer instantanément une page lors de l'utilisation des boutons de navigation arrière et avant. Ce mécanisme, présent depuis longtemps dans les navigateurs, a un impact significatif sur les Core Web Vitals et l'expérience utilisateur. L'auteur détaille comment mesurer et optimiser l'utilisation de BFCache, ainsi que les facteurs qui peuvent l'empêcher, comme l'événement 'unload' ou certaines directives de cache. Une lecture intéressante pour les passionnés de performance web.
Cet article explore les nuances et les problèmes liés au Time-To-First-Byte (TTFB), une métrique de performance web souvent mal comprise. Marx souligne que le TTFB a plusieurs définitions et est composé de plusieurs sous-parties, ce qui rend difficile la comparaison des mesures et le débogage des problèmes. Il aborde également les facteurs qui peuvent influencer les valeurs de TTFB, y compris les technologies comme HTTP/2 et HTTP/3, et propose des recommandations pour une utilisation plus judicieuse de cette métrique. Le billet est le premier d'une série qui approfondira l'impact de diverses technologies sur le TTFB.
Barry Pollard, expert en performance web chez Google, explique dans cet article les impacts négatifs des paramètres d'URL (URL params) sur les performances des sites web. Ces paramètres, souvent utilisés pour le suivi analytique, peuvent empêcher le cache des pages, même lorsque le contenu est identique, ce qui entraîne des chargements inutiles et une surcharge des serveurs. L'auteur illustre ce problème à travers trois scénarios concrets et souligne l'importance de la mise en cache pour optimiser la performance web.
Cet article de Jordy Scholing, publié dans le Web Performance Calendar, explore pourquoi l'optimisation pour le 75ème percentile (p75) des métriques de performance web, bien qu'utile, ne suffit pas pour offrir une expérience utilisateur optimale. Il argue que se concentrer sur le 90ème percentile (p90) permet de mieux capturer les problèmes réels d'expérience utilisateur, notamment pour les utilisateurs à haute intention, mobiles ou ayant des attentes élevées. L'auteur souligne que le p75, bien qu'utile pour le SEO, ne répond pas à la question de savoir si presque tous les utilisateurs sont satisfaits. En optimisant pour le p90, on identifie des problèmes tels que des temps de réponse instables, des scripts tiers problématiques et des pics de JavaScript sur des appareils lents, ce qui permet d'améliorer réellement les taux de conversion et l'engagement. L'article encourage les experts en performance à viser plus haut que le p75 pour offrir une expérience utilisateur plus équitable et efficace.
Conor McCarthy, ingénieur en support client chez DebugBear, partage cinq enseignements clés tirés de 100 revues de vitesse de site réalisées en 2025. Il souligne la valeur de Lighthouse, souvent utilisé comme référence, mais recommande de privilégier les données CrUX et de surveillance des utilisateurs réels pour les grandes équipes. Il note également que les seuils de Total Blocking Time (TBT) sont élevés, avec la plupart des pages dépassant 1 seconde, mais que cela n'impacte pas nécessairement l'expérience utilisateur réelle, comme le montre les données CrUX.
L'article explique comment l'auteur a résolu un problème de vitesse lente sur un câble USB-C en découvrant que l'orientation du câble affectait les performances. Il explore ensuite les détails techniques des connecteurs USB-C, qui possèdent 24 broches, chacune ayant une fonction spécifique. L'auteur fournit un diagramme simplifié des broches et explique que certaines broches sont interconnectées à l'intérieur du câble pour permettre la réversibilité. Il mentionne également que tous les câbles et chargeurs n'utilisent pas toutes les broches disponibles.
L'article explore les différentes phases de l'optimisation du Largest Contentful Paint (LCP), une métrique clé des Core Web Vitals. Il explique que le LCP peut être décomposé en quatre sous-parties : TTFB (Time to First Byte), Resource Load Delay, Resource Load Duration et Element Render Delay. Chaque phase identifie des goulots d'étranglement spécifiques et propose des solutions pour les résoudre. L'article souligne l'importance de comprendre ces phases pour diagnostiquer et améliorer les performances de chargement des pages web, en particulier pour les images, qui représentent la majorité des éléments LCP.
L'article explore comment des techniques anciennes et des API natives du navigateur surpassent les frameworks modernes en termes de performance. L'auteur présente multicardz, un outil de gestion de données spatiales, qui utilise des bitmaps pour les requêtes backend, réduisant ainsi les temps de traitement. Pour le frontend, il utilise DATAOS (DOM As The Authority On State), une approche où le DOM est la source de vérité pour l'état de l'application, éliminant ainsi la nécessité de synchroniser un état séparé. Le résultat est une application performante avec un bundle JavaScript de seulement 32KB, un score Lighthouse de 100, et des temps de réponse extrêmement rapides.
Morgan Murrah explique comment il a optimisé les animations de son site web en utilisant le compositeur (compositor), un processus GPU séparé qui améliore les performances des animations CSS. Il partage son expérience avec deux animations : des nuages en mouvement et un soleil avec des ondes pulsantes. En analysant les performances avec Chrome, il découvre que l'animation des nuages, utilisant la propriété left, génère une activité excessive dans le thread principal. Il apprend à convertir cette animation en une animation composée, utilisant la propriété transform au lieu de left, ce qui réduit significativement l'impact sur les performances. Un article accessible pour comprendre l'importance du compositeur dans les animations web.
L'article explore la possibilité d'utiliser l'IA pour codifier des bonnes pratiques de performance web, inspirées de l'outil YSlow des années 2000. L'auteur propose de former un modèle d'IA avec des données structurées issues de l'HTTPArchive, en comparant des pages lentes et rapides, pour distiller des règles de performance web adaptées à l'ère actuelle. L'objectif est de revivre l'esprit de YSlow avec une approche moderne et automatisée.
React 19.2 améliore l'optimisation de l'INP (Interaction to Next Paint) avec deux nouvelles fonctionnalités clés. La première est le composant
Cet article met en lumière les lacunes des études de cas souvent utilisées pour démontrer l'impact de la performance web sur les revenus. Il souligne que ces études, bien que populaires, sont souvent biaisées, incomplètes ou mal contextualisées, ce qui nuit à la crédibilité de l'industrie. Il prend comme exemples l'étude d'Amazon sur la perte de revenus de 1% pour 100ms de retard (données obsolètes, manque de contexte) et l'étude de Rossignol (variables confondantes). L'auteur encourage à être critique face à ces études et à privilégier des données solides et contextuelles pour convaincre les parties prenantes.