Aller directement au programme détaillé

Intervenant‧e‧sIntervenants et Intervenantes


Aperçu

Navigateur : les coulisses du chargement #

Pour comprendre la Performance Web, les développeurs doivent d’abord comprendre comment fonctionne un navigateur. Partons à la découverte du navigateur et de ce qu’il s’y passe quand un internaute demande une page.

consulter le support

Estelle Weyl

Présenté par
Estelle Weyl

Estelle est consultante, formatrice, auteure et conférencière. Elle organise la conférence #Perfmatters. Elle documente les technologies Web pour MDN concernant l’accessibilité, les performances et CSS. Elle parle et anime des ateliers sur le développement Web dans le monde entier et ses livres ont été traduits dans plus de 14 langues. Elle code en CSS, HTML et JavaScript depuis 1999.


Comment lier performance et écologie ? #

Le Web doit être rapide, optimisé et performant. Mais rendre un site performant n’est pas chose facile lorsqu’on essaye de prendre en compte les problématiques écologiques soulevées par le code généré ou l’ajout de serveurs à des infrastructures. La performance n’est pas green, mais elle pourrait.

J’explique dans cette conférence les défis écologiques que pose le numérique et ceux qui sont spécifiquement liés à certaines optimisations de la Performance Web pour vous aider à les relever. Ensemble, construisons un Web rapide, performant et responsable.

consulter le support

Romuald Priol

Présenté par
Romuald Priol

La programmation informatique est avant tout une passion, tout comme le sont les nouvelles technologies. Orienté dans un premier temps dans le monde du Web, j’ai rapidement appris à maitriser les différents Frameworks PHP ( Zend, Symfony, Phalcon…) et JavaScript (Vue.Js…), je me suis intéressé de près aux bonnes pratiques du secteur (accessibilité, SEO, etc…), avant de détourner mon regard vers un autre monde, celui de la mobilité, (Windows Phone, FirefoxOs, Android) en natif et en hybride via différentes solutions (Xamarin, PhoneGap, Unity, Ionic..) et du développement Windows (C# / XAML).

Ces différents domaines d’expertises m’ont permis de définir les problématiques de performance et d’architecture de beaucoup de projets, et de me pencher sérieusement sur la conception responsable en prenant en compte l’éco-conception des applications web et natives et tous les horizons du numérique responsable.


Why does frontend performance matter? #

L’idée de cette intervention est de vous donner mon opinion sur l’importance de la Performance Web et son énorme impact sur les utilisateurs de services gouvernementaux. Je me concentrerai sur le site Web du Gouvernement du Royaume-Uni (GOV.UK). Je présenterai d’abord un historique du Service Numérique Gouvernemental et de GOV.UK avant de m’intéresser à qui sont les utilisateurs et les connexions / appareils qu’iels utilisent. L’accent sera mis sur ce qui se passe quand la performance web d’un site gouvernemental de ce type est médiocre et l’impact que cela peut avoir sur les personnes qui dépendent des services essentiels que ces sites proposent. Nous aborderons ce que nous avons fait, ce que nous faisons et de ce que nous planifions pour l’avenir en ce qui concerne la Performance Web, pour l’ensemble des sites du gouvernement.

Cette intervention s’adresse à toute personne intéressée par la Performance Web, qui aimerait connaître le point de vue du Gouvernement à ce sujet. C’est un secteur où il n’y a pas de concurrence et où si un utilisateur ne peut pas trouver rapidement et facilement l’information dont iel a besoin, il n’y a pas d’alternative.

consulter le support

Matt Hobbs

Présenté en anglais par
Matt Hobbs

Matt est Responsable du développement Front-End au Service Numérique Gouvernemental du Royaume-Uni. Développeur Front expérimenté, il est passionné par l’utilisation de ses compétences pour créer des interfaces utilisateur accessibles et performantes. Matt se fait un point d’honneur de rester à la pointe de la technologie et des outils les plus récents, s’intéresse à tous les aspects du développement d’interfaces et est un ardent défenseur des bonnes pratiques Web.


Compresser efficacement ses images : un problème d’échelle #

Compresser une image n’est déjà pas facile, et le faire sur de grands volumes et à moindre coût est un challenge.

Nous allons voir ensemble les grands principes de l’optimisation et les techniques qui en découlent : redimensionnement en fonction du contenu, compression selon la qualité perçue, comment choisir une image en fonction de la capacité de l’écran, du support navigateur et même de la qualité de la connexion du navigateur. Enfin nous verrons comment appliquer ces techniques à l’échelle de services comme Akamai et Cloudinary grâce à notre expérience du sujet chez Fasterize.

Anthony Barré

Présenté par
Anthony Barré

Expert webperf chez Fasterize, je suis un des développeurs du moteur d’optimisation au cœur de la solution. Je travaille essentiellement sur des optimisations Front-End.


Chérie, j’ai rétréci mes bundles JS #

Sur un site à destination de conseillers d’une grande banque, nous nous sommes heurtés à des problèmes de performance dus à la quantité de JavaScript que nous envoyions au client.

Nous avons réduit le temps de chargement de notre application de 9 à 2 secondes, et ce grâce à plusieurs méthodes : l’analyse de bundle, le code splitting et la déduplication de dépendances. Pendant ce talk, je couvrirai les sujets suivants:

  • Séparer simplement son bundle JavaScript
  • Analyser et monitorer la taille de son JavaScript
  • Dédupliquer ses dépendances
  • Bien choisir ses dépendances
  • Code splitting vs. bundle splitting

J’illustrerai ces sujets avec les impacts concrets de chacune de ces méthodes sur la performance de mon projet.

À la fin du talk, vous connaitrez toutes les bonnes pratiques pour garder une faible taille de JavaScript, et aurez à votre disposition un support de formation pour faire de vous des experts.

Antoine Kahn-Dubois

Présenté par
Antoine Kahn-Dubois

Antoine est un développeur agile depuis quatre ans chez Theodo, passionné de performances, JavaScript et Python. Il est convaincu que nous pouvons sauver le monde en réduisant la taille de nos bundles JavaScript.


Dans quoi s’embarque-t-on en lançant un projet d’optimisation de la webperf ? #

Envie de lancer ou en phase de lancement d’un projet d’optimisation de la Performance Web ? Abordons ensemble les différentes étapes de maturation d’un projet de webperf en entreprise au travers du retour d’expérience de OUI.sncf, mais également grâce à des retours d’expériences d’autres sites e-commerce ayant eu la même démarche. Durant cette présentation, nous aborderons :

  • Les conditions de lancement d’un projet webperf (quel élément déclencheur ou argument permettent la prise de conscience de la nécessité d’un tel projet ?) ;
  • La préparation (de qui s’entourer, comment s’organiser ?) ;
  • La montée en compétence (comment aborder la phase d’apprentissage, fixer des objectifs, revoir son monitoring) ;
  • Les obstacles (quelle posture adopter dans des cas d’intérêts divergents) ;
  • La phase de maturité (sensibiliser les équipes plus largement, déterminer les relais de l’acculturation) ;
  • Et bien sûr, la fin (quand peut-on dire qu’un projet d’optimisation est terminé ?).
Quentin Mathieu

Animé
Quentin Mathieu

Expert QOE pour OUI.sncf, œuvre pour la maîtrise du SI au service de l’expérience utilisateur.

Mathilde Lassort

Animé
Mathilde Lassort

Product Strategist chez OUI.sncf, j’accompagne les équipes dans la stratégie produit.


Responsible JavaScript #

Bien que les performances des moteurs JavaScript dans les navigateurs aient connu une amélioration continue, la quantité de JavaScript que nous servons augmente sans relâche. Nous devons utiliser JavaScript de manière plus responsable, ce qui signifie que nous devons nous fier à des fonctions de navigation natives par prudence, utiliser HTML et CSS lorsque c’est approprié, et savoir quand rajouter du JavaScript en fait trop.

Nous explorerons ce qu’il advient de la performance et de l’accessibilité lorsque les périphériques sont inondés de plus de JavaScript qu’ils ne peuvent le gérer. Nous nous plongerons également dans de nouvelles techniques permettant d’adapter la livraison des scripts en fonction des capacités du matériel et de la qualité de la connexion réseau. Lorsque vous sortirez de cette session, vous serez équipé de nouvelles connaissances pour rendre vos sites aussi rapides qu’ils sont beaux.

consulter le support (en)

Jeremy Wagner

Présenté en anglais par
Jeremy Wagner

Jeremy Wagner est un consultant en Performance Web américain, travaillant pour Siteimprove. Il écrit et parle souvent sur la Performance et travaille à rendre le web plus rapide pour tout le monde, en tous lieux.


Chaperones and curfews: minimising 3rd party impact #

Le poids des sites Web augmente d’année en année. Le gros de cette croissance ne vient pas du code écrit par les organisations qui les gèrent… il vient des scripts tiers. Même si l’époque où il était viable de tout construire en interne est révolue depuis longtemps, l’impact sur les performances de ces scripts commence à devenir incontrôlable. Alors bien sûr, nous n’allons pas devenir aigris et jeter tout ce petit monde dehors, mais ce n’est pas une raison pour ne pas modérer la fête. Durant cette présentation, nous ne chercherons pas à éliminer complètement les tierces parties – personne n’aime qu’on lui enlève ses jouets – au lieu de cela, nous adopterons l’approche pratique consistant à accepter que les tierces parties restent tout en examinant les stratégies que nous pouvons employer pour garantir la performance et nous protéger contre de futurs ralentissements, pannes et abus.

consulter le support (en)

Ryan Townsend

Présenté en anglais par
Ryan Townsend

Avec plus de 15 ans d’expérience dans le développement web, et une passion inébranlable pour la WebPerf, Ryan Townsend est le directeur technique de Shift Commerce - une plateforme e-commerce SaaS pour les détaillants ambitieux.

Sa vision pragmatique et axée sur la performance impliquent que même quand il porte une chemise, ses manches restent bien retroussées : bien qu’il soit cadre, sa place préférée est là, au cœur de l’action, avec son équipe.

À l’extérieur du bureau, il ramasse des objets lourds dans des gymnases ou tombe de son VTT sur le flanc des collines.


Progressive Web App et performance #

Il y a 2 ans, l’Équipe était parmi les premiers en France à lancer une Progressive Web App pour son site mobile. Les gains webperf de ce changement nous ont conduits cette année à refondre entièrement notre site desktop sur ce modèle. Dans ce cadre, je vous propose un retour d’expérience des différentes actions mises en place en faveur de la webperf, et de partager les premiers résultats.

Raphaël Dardeau

Présenté par
Raphaël Dardeau

Responsable des développements web à L’Équipe, premier site d’informations sportives français.


HTTP/3 : c’est une question de transport ! #

Le HTTP ou Hyper Text Transfer Protocol est le protocole du Web. L’annonce de HTTP/3 début novembre 2018 en a surpris plus d’un : moins de 4 ans le séparent de HTTP/2, alors que 18 ans s’étaient écoulés entre HTTP/1.1 et HTTP/2.

Néanmoins cette version apporte une vraie complémentarité au travail réalisé sur HTTP/2, notamment sur les problématiques de latence.

La latence est certainement l’enemie numéro 1 de la performance web. On la trouve à tous les niveaux : front-end, back-end, protocole réseau, matériel, etc. La latence doit donc être combattue d’une manière transverse pour fournir à nos utilisateurs la meilleure expérience possible.

Ce talk reviendra sur le pourquoi de cette version 3 du protocol du Web, ce qu’elle apporte et ce qu’elle change, et ce que peuvent en attendre les développeurs Web.

Ce sera l’occasion également de présenter les challenges qui vont se poser à la mise en place de HTTP/3.

Le public visé est : toute personne avec un background technique travaillant autour du ·eb (dev, devops, ingénieur réseau).

Les grandes lignes de l’intervention seront:

  • les notions de latence et bande passante
  • la problèmatique de latence liée à TCP + TLS
  • l’introduction du protocole de transport QUIC pour résoudre ces problèmes
  • les limitations imposées par TCP sur HTTP/2
  • les challenges quant à la mise en place de HTTP/3
Benoit Jacquemont

Présenté par
Benoit Jacquemont

Benoit Jacquemont est tombé dans le web en 2000 après avoir une première expérience sur des logiciels d’encaissements. De Java à PHP, de Oracle à MySQL et des applications de gestions aux sites de eCommerce, il roule sa bosse sur les projets, toujours à forte composante OpenSource, au sein du groupe Smile. Il en devient le CTO en 2009 alors que l’entreprise compte près de 450 salariés. En janvier 2013, il co-fonde Akeneo avec Frédéric de Gombert, Nicolas Dupont et Yoav Kutner. L’aventure startup commence alors pour lui, en tant que CTO d’Akeneo.


Retour d’expérience sur 4 ans d’utilisation d’un outil de surveillance synthétique chez SeLoger #

Il y a quelques années, SeLoger a beaucoup investi dans la performance applicative de ses sites Web. Cela s’est concrétisé par la création de postes, l’achat d’outils et la création d’un outil de Synthetic Monitoring basé sur WebPageTest. Aujourd’hui nous avons migré ce dernier sur un outil du marché.

Pendant cette conférence, vous découvrirez dans un 1er temps pourquoi et comment nous avons créé un outil de Synthetic Monitoring. Nous répondrons aux questions suivantes.

  • Pourquoi ne pas avoir pris un outil du marché ?
  • Comment nous l’avons architecturé ?
  • Comment et pourquoi nous l’avons fait évoluer ?
  • Comment nous l’avons utilisé en interne pour créer une culture, un référentiel orienté Web Performance ?

Puis dans un second temps, pourquoi et comment nous avons réalisé cette migration :

  • Pourquoi abandonner un outil sur mesure ?
  • Quels impacts sur nos projets ?
  • Quels choix avons-nous effectués tout au long du processus ?
  • Qu’avons-nous appris ?
  • Quels sont les pièges à éviter ?
  • Quels compromis avons-nous acceptés ?

Je commencerai par présenter le contexte de SeLoger et notre défunt outil de Synthetic Monitoring. Puis nous déroulerons le processus de sélection que nous avons mis en place.

Antonio Gomes Rodrigues

Présenté par
Antonio Gomes Rodrigues

Antonio Gomes Rodrigues est expert dans le domaine des performances applicatives depuis plus de 10 ans. Ses missions l’ont amené à travailler :

  • sur les performances des sites WEB à fort trafic ;
  • sur les performances d’une application pour courtiers ;
  • sur les performances de clients lourds, d’applications dans le cloud, d’application WEB, etc.

Avec divers outils (Profiler, APM, Synthetic Monitoring, load test…et dans diverses missions : tests de charge, mise en place de stratégies de performance, formations, audits de performance, diagnostics, etc.

Il est actuellement responsable performance chez SeLoger, contributeur et membre PMC du projet JMeter au sein de la fondation Apache Software - ASF.


Comment PagesJaunes s’est hissé dans le top 10 du classement webperf #

Ce retour d’expérience retrace chronologiquement tous les travaux réalisés par mon équipe depuis 1 an pour améliorer la webperf sur www.pagesjaunes.fr. Je passe en revue tout ce que l’on a mis en place, les gains obtenus mais les échecs également.

Loïc Troquet

Présenté par
Loïc Troquet

Responsable du pôle architecture www.pagesjaunes.fr. Spécialiste des développements d’applications web à forte visibilité. ScrumMaster certifié. Spécialisations : Java, Spring, Continuous Delivery, Webperf, Sécurité, Git, Maven, Scrum, Kanban, Lean, Management 3.0


Keeping Wikipedia Fast #

L’équipe Performance de la Wikimedia Foundation est chargée de mesurer la performance de Wikipedia. On met en place une surveillance et pouf, c’est parti ? En théorie, c’est facile, mais dans la pratique, c’est une autre histoire.

Dans cet exposé, examinons comment nous effectuons des tests de performance à la Wikimedia Foundation à l’aide d’outils synthétiques et comment cela s’articule avec les mesures réalisées auprès d’utilisateurs réels. Nous parlerons de la mise en place, des quelques études de cas où nous avons trouvé des régressions et nous passerons en revue les leçons que nous avons tirées de nos erreurs.

consulter le support (en)

Peter Hedenskog

Présenté en anglais par
Peter Hedenskog

Peter travaille dans l’équipe Performance de la Wikimedia Foundation où il mesure la performance de Wikipédia à l’aide de tests synthétiques et de RUM. Avant de rejoindre la fondation, il a travaillé comme consultant en Performance Web pour les plus grandes marques suédoises. Peter a également créé le populaire outil de Performance Web open source sitespeed.io.


Comment interpréter les mesures de performance réelles (RUM metrics) #

Grâce aux APIs côté client telles que NavigationTiming, nous avons la possibilité de collecter énormément d’informations sur la Performance Web réelle de nos utilisateurs. Cependant, la nature organique de ces données crée de nombreux pièges dans lesquels il est facile de tomber quand on tente de les interpréter.

Nous allons voir ensemble de bonnes pratiques en la matière, des exemples réels provenant du trafic de Wikipedia ainsi que des résultats de recherche récents que nous avons publié sur ce sujet. Nous chercherons à savoir quelles mesures RUM sont les plus pertinentes. Enfin, nous ferons un tour d’horizon de futures APIs très prometteuses en cours de développement au sein du groupe de travail Web Performance du W3C, et partagerons notre retour d’expérience sur celles-ci, les ayant testées récemment sur Wikipedia dans le cadre d’Origin Trials de Chrome.

Gilles Dubuc

Présenté par
Gilles Dubuc

Après plus d’une dizaine d’années d’expérience en tant que développeur Full Stack, Gilles Dubuc a rejoint la Fondation Wikimedia en 2014.

Il est l’un des membres fondateurs de l’équipe Performance au sein de la fondation, créée en 2015. Il contribue depuis au fait de rendre Wikipedia et les autres projets Wikimedia les sites web les plus performants possibles, en intervenant à tous les niveaux de l’architecture et en participant au futur de la performance Web au sein du W3C et à travers des travaux de recherche.


Diminuer le poids d’une interface d’un client mail via CSS / SVG #

Je travaille actuellement sur la v4 de ProtonMail. L’existant n’est pas toujours facile à manœuvrer : une inévitable dette technique (et donc de performance), des CSS lourdes, un manque d’uniformité, etc.

L’occasion d’une refonte est parfaite pour repenser l’architecture des CSS et prendre les bonnes décisions pour préparer la performance future : les gains substantiels se préparent au long cours, des choix qui peuvent sembler anecdotiques se révèlent très efficaces quand on doit « scaler » et penser internationalisation.

Je vous propose un retour d’expérience sur ce travail au long cours, des astuces notamment avec SVG (les requêtes les plus performantes sont celles… que l’on ne fait pas :) ), et principalement une manière d’architecturer CSS qui permet d’en réduire drastiquement le poids. Et donc d’envisager sereinement des notions sympathiques comme le budget de performance, les critical CSS, etc.

L’intégrateur n’a pas dit son dernier mot !

consulter le support

Nicolas Hoffmann

Présenté par
Nicolas Hoffmann

Nicolas est un soldat monté pacifiquement au front (-end) depuis plus de 15 ans, qui a bossé en web agency en Suisse pendant une dizaine d’année, et qui travaille actuellement entre autres sur l’UI et CSS en tant que quark… chez ProtonMail.

Directeur du collectif OpenWeb, conférencier à des événements comme Paris-Web, Codeurs en Seine, Sud Web, etc., aussi auteur du micro-framework CSS Röcssti, certifié Expert qualité Opquast, également auteur de scripts accessibles via le projet Van11y - avec de l’ARIA dedans - et de plus d’une cinquantaine d’articles sur la conception de CSS, la sécurité, la qualité Web, etc., il est parfois délicatement surnommé « le Suisse-Allemand de la qualité Web » à cause d’un bon score à la certification Opquast. Le pire, c’est qu’il prend ce surnom comme un compliment.


UX vs DX #

Rapide à coder. Rapide à montrer. Mais pourquoi devrait-on choisir entre l’un et l’autre ? Nos sites sont censés être réactifs, internationalisables, sécurisés, accessibles et performants. Il est logique d’utiliser tous les outils disponibles pour implémenter rapidement des fonctionnalités, mais il faut faire attention à ce que vos outils n’aient pas un impact négatif sur la facilité d’utilisation. Voyons quels sont les problèmes communs et comment ne pas sacrifier la qualité au profit du confort des développeurs.

Dans cette session, nous abordons les problèmes de création de sites sans compromettre aucune exigence.

consulter le support

Estelle Weyl

Présenté en anglais par
Estelle Weyl

Estelle est consultante, formatrice, auteure et conférencière. Elle organise la conférence #Perfmatters. Elle documente les technologies Web pour MDN concernant l’accessibilité, les performances et CSS. Elle parle et anime des ateliers sur le développement Web dans le monde entier et ses livres ont été traduits dans plus de 14 langues. Elle code en CSS, HTML et JavaScript depuis 1999.