des bonness pratiques a changer côté dev front pour migrer vers HTTP/2

A performance budget is just what it sounds like: you set a “budget” on your page and do not allow the page to exceed that. This may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or size of the page.
(...)
Once those goals are set, you stick to them. Anytime you want to add something to a page, you need to ensure it stays within budget. Steve Souders talked about the three options you have if something does not fit within the budget:

1. Optimize an existing feature or asset on the page.
2. Remove an existing feature or asset from the page.
3. Don’t add the new feature or asset.

Le budget performance correspond à la valeur max autorisée pour une métrique de performance (temps de chargement, nombre de requêtes ou poids de la page). On peut ensuite tester le "budget" au cours de l'intégration continue avec un outils comme SiteSpeed.io et remonter une alerte en cas de dépassement.

Pour analyser la performance d'un site web. Pas mal de fonctionnalités intéressantes:

• Dashboard Graphite/Grafana (procédure avec Docker incluse)
• Check Performance Budget
• Intégration WebPageTest et Google PageSpeed Insights
• Intégration CI avec Jenkins & Travis

Description des Headers HTTP utilisés pour mettre en cache du contenu

Introduction au Real User Monitoring pour récupérer les métriques (temps de chargement des pages...) coté navigateur web des utilisateurs

Explication détaillée sur les types d'attaques DDOS et les solutions pour s'en protéger

Une très bonne et très complète explication du concept et des enjeux des CDN

Pour blocker les publicités tout en allégeant la charge induite par tous les addblock like, pensez au fichier hosts qui redirige les sites de pubs vers localhost. Pour ma part je teste https://github.com/StevenBlack/hosts qui permet de générer un fichiers hosts à partir de plusieurs liste connues