Smashing Podcast Épisode 34 Avec Harry Roberts : Quel est l'état des performances Web ?

Dans cet épisode, on parle de Web Performance. À quoi ressemble le paysage des performances en 2021 ? J'ai parlé avec l'expert Harry Roberts pour le savoir.

Afficher les remarques

Harry organise un atelier Web Performance Masterclass avec Smashing en mai 2021. Au moment de la publication, d'importantes remises pour les lève-tôt sont toujours disponibles.

• Harry sur Twitter
• Le site de consultation de Harry CSS Wizardry
• Cours vidéo Tout ce que j'ai fait pour rendre CSS Wizardry Fast, y compris 15 % de réduction
• Questions pour les Consultants eBook incluant 15% de réduction
• Guide Web.dev pour Web Vitals
• Le batteur à œufs OXO GoodGrips préféré de Drew

Mise à jour hebdomadaire

• Tendances du design Web 2021 : le rapport rédigé par Suzanne Scacca
• Utilisation de Grommet In React Applications écrites par Fortune Ikechi
• Comment construire une API Node.js pour Ethereum Blockchain écrit par John Agbanusi
• Comment nous avons amélioré les performances de SmashingMag écrit par Vitaly Friedman
• Quand dire non aux projets indépendants écrit par Becca Kennedy

Transcription

Drew McLellan : C'est un ingénieur consultant indépendant en performance Web de Leeds au Royaume-Uni. Dans son rôle, il aide certaines des organisations les plus importantes et les plus respectées au monde à offrir des expériences plus rapides et plus fiables à leurs clients. Il est un Google Developer Expert invité, un Cloudinary Media Developer Expert, un développeur primé et un conférencier international. Nous savons donc qu'il connaît son métier en matière de performances Web, mais saviez-vous qu'il a 14 bras et sept jambes ? Mes amis Smashing, veuillez accueillir Harry Roberts. Salut Harry, comment vas-tu ?

Harry Roberts : Hé, je suis super merci beaucoup. Evidemment les 14 bras, sept jambes… posant toujours ses problèmes habituels. Impossible d'acheter un pantalon.

Drew : Et des vélos.

Harry : Ouais. Eh bien, j'ai trois vélos et demi.

Drew : Je voulais donc vous parler aujourd'hui, pas de vélos malheureusement, même si ce serait amusant en soi. Je voulais vous parler de performance web. C'est un sujet qui me passionne personnellement, mais c'est l'un de ces domaines où je m'inquiète, quand je détourne les yeux du ballon et que je m'implique dans une sorte d'autre travail, puis que je reviens à faire un peu de travail de performance, Je crains que les connaissances avec lesquelles je travaille ne deviennent rapidement obsolètes… Les performances Web évoluent-elles aussi rapidement que je le perçois ces jours-ci ?

Harry : C'est… Je ne dis même pas ça juste pour être gentil avec toi, c'est une très bonne question parce que j'y ai pas mal réfléchi ces derniers temps et je dirais qu'il y en a deux moitiés. Une chose que j'essaierais de dire aux clients, c'est qu'en fait, ça ne bouge pas aussi vite. Principalement parce que, et c'est l'extrait sonore que j'utilise toujours, vous pouvez parier sur le navigateur. Les navigateurs ne sont pas vraiment autorisés à changer fondamentalement leur fonctionnement, car, bien sûr, il y a deux décennies d'héritage qu'ils doivent respecter. Donc, en général, si vous pariez sur le navigateur et que vous savez comment ces composants internes fonctionnent, et TCP/IP qui ne change jamais… Donc, certaines choses qui sont assez gravées dans le marbre, ce qui signifie que les meilleures pratiques seront, dans l'ensemble, toujours bonnes pratiques en ce qui concerne les fondamentaux.

Harry : Là où ça devient plus intéressant, c'est… Ce que je vois de plus en plus, c'est que nous nous retrouvons dans les coins quand il s'agit de problèmes de vitesse du site. Nous nous créons donc beaucoup de problèmes. Donc, ce que cela signifie de manière réaliste, c'est la performance… c'est le poteau de but mobile, je suppose. Plus le paysage ou la topographie du web change, et plus la façon dont il se construit et dont nous travaillons, plus nous nous posons de nouveaux défis. Ainsi, l'avènement de faire beaucoup plus de travail sur le client pose des problèmes de performances différents de ceux que nous aurions résolus il y a cinq ans, mais ces problèmes de performances concernent toujours les composants internes du navigateur qui, dans l'ensemble, n'ont pas changé depuis cinq ans. Donc, cela dépend en grande partie… Et je dirais qu'il y a certainement deux côtés clairs… J'encourage mes clients à s'appuyer sur le navigateur, à s'appuyer sur les normes, car elles ne peuvent pas simplement être modifiées, les poteaux de but ne bougent pas vraiment . Mais, bien sûr, cela doit se fondre avec des pratiques de développement plus modernes et, peut-être légèrement plus intéressantes. Donc tu gardes ton… Bon, j'allais dire « Un pied dans les deux camps » mais avec mes sept pieds, il faudrait que je… quatre et trois.

Drew : Vous avez mentionné que les fondamentaux ne changent pas et que des choses comme TCP/IP ne changent pas. L'une des choses qui a changé dans… je dis "ces dernières années", cela remonte probablement un peu en arrière maintenant, mais c'est HTTP en ce sens que nous avions ce protocole établi HTTP pour communiquer entre les clients et les serveurs, et cela a changé et puis nous avons obtenu H2 qui est alors tout binaire et différent. Et cela a beaucoup changé le… C'était pour des raisons de performances, c'était pour supprimer certaines des limitations existantes, mais c'était un changement et la façon dont nous devions optimiser pour ce protocole a changé. Est-ce maintenant stable ? Ou est-ce que ça va encore changer, ou…

Harry : Donc, une chose sur laquelle j'aimerais en savoir plus est la seconde moitié de la question, le changement à nouveau. J'ai besoin de me pencher davantage sur QUIC et H3, mais c'est un peu trop loin pour être utile à mes clients. En ce qui concerne H2, les choses ont beaucoup changé, mais je pense sincèrement que H2 est plein de fausses promesses et je pense qu'il a été précipité, ce qui est remarquable compte tenu du lancement de H1… Et je veux dire 1.1, c'était en 1997, nous avons donc beaucoup de temps pour travailler sur H2.

Harry : Je suppose que le principal avantage est que les développeurs Web le comprennent ou perçoivent qu'il est maintenant illimité dans les demandes de vol. Donc, plutôt que six demandes envoyées et/ou six demandes en vol à la fois, potentiellement illimitées, infinies. Apporte des problèmes vraiment intéressants car… c'est assez difficile à décrire sans aides visuelles mais vous avez toujours la même quantité de bande passante disponible, que vous utilisiez H1 ou H2, le protocole ne rend pas votre connexion plus rapide. Il est donc tout à fait possible que vous puissiez inonder le réseau en demandant 24 fichiers à la fois, mais vous n'avez pas assez de bande passante pour cela. Donc, vous n'allez pas vraiment plus vite parce que vous ne pouvez gérer, peut-être, qu'une fraction de cela à la fois.

Harry : Et vous devez aussi penser à la façon dont les fichiers réagissent. Et c'est un autre pro-tip que je passe sur les ateliers clients et cetera. Les gens regarderont une cascade H2 et ils verront qu'au lieu des six demandes de répartition traditionnelles, ils pourraient en voir 24. La répartition de 24 requêtes n'est pas vraiment utile. Ce qui est utile, c'est lorsque ces réponses sont renvoyées. Et ce que vous remarquerez, c'est que vous pouvez envoyer 24 requêtes, donc votre côté gauche de votre cascade a l'air vraiment sympa et raide, mais ils reviennent tous de manière séquentielle assez échelonnée parce que vous devez limiter la quantité de bande passante donc vous ne pouvez pas répondre à toutes les réponses en même temps.

Harry : Eh bien, l'autre chose est que si vous remplissiez toutes les réponses en même temps, vous entremêleriez les réponses. Ainsi, vous obtenez les premiers 10 % de chaque fichier et les 20 % suivants… 20 % d'un fichier JavaScript est inutile. JavaScript n'est pas utilisable tant que 100 % de celui-ci n'est pas arrivé. Donc, ce que vous verrez, c'est en fait la façon dont une cascade H2 se manifeste quand vous regardez la réponse… Ça ressemble beaucoup plus à H1 de toute façon, c'est beaucoup plus décalé. Donc, H2, je pense qu'il a été survendu, ou peut-être que les ingénieurs n'ont pas été amenés à croire qu'il y avait des limites à son efficacité. Parce que vous verrez des gens partager trop leurs actifs et qu'ils pourraient en avoir vingt… gardons le nombre 24. Au lieu d'avoir deux gros fichiers JS, vous pourriez avoir 24 petits paquets. Ils reviendront toujours assez séquentiellement. Ils n'arriveront pas tous en même temps parce que vous ne vous êtes pas magiquement procuré plus de bande passante.

Harry : Et l'autre problème est que chaque requête a une latence constante. Supposons donc que vous demandiez deux gros fichiers et qu'il s'agisse d'un aller-retour de cent millisecondes et d'un téléchargement de 250 millisecondes, soit deux fois 250 millisecondes. Si vous multipliez jusqu'à 24 requêtes, vous avez toujours une latence constante, que nous avons décidée de 100 millisecondes, donc maintenant vous avez 2400 millisecondes de latence et 24 fois… au lieu de 250 millisecondes de téléchargement disons ses 25 millisecondes de téléchargement, cela prend en fait plus de temps car la latence reste constante et vous multipliez simplement cette latence sur plus de demandes. Je verrai donc des clients qui auront lu que H2 est cette formule magique. Ils vont éclater… Oh ! Ils n'ont pas pu simplifier le processus de développement, nous n'avons pas besoin de faire de regroupement ou de concaténation, etc., et cetera. Et finalement, cela finira plus lentement parce que vous avez réussi à répartir vos demandes, ce qui était promis, mais votre latence reste constante, vous avez donc juste n fois plus de latence dans le navigateur. Comme je l'ai dit, vraiment difficile, probablement inutile d'essayer d'expliquer cela sans visuels, mais il est remarquable de voir comment H2 se manifeste par rapport à ce que les gens espèrent qu'il pourrait faire.

Drew: Y a-t-il encore des avantages à ce processus de partitionnement dans le sens où, d'accord, obtenir tout le lot prend toujours le même temps, mais au moment où vous obtenez 100% du premier 24, vous pouvez commencer à travailler dessus et vous pouvez commencer à l'exécuter avant la fin du 24.

Harry : Oh, mec, une autre excellente question. Donc, absolument, si les choses se passent correctement et que cela se manifeste dans une réponse plus H1, l'idée serait que le fichier un retourne en premier, deux, trois, quatre, puis ils peuvent s'exécuter dans l'ordre où ils arrivent. Ainsi, vous pouvez réellement raccourcir le temps cumulé en vous assurant que les choses arrivent en même temps. Si nous examinons une page Web au lieu d'une cascade et que vous remarquez que les demandes sont entrelacées, c'est une mauvaise nouvelle. Parce que comme je l'ai dit, 10% d'un fichier JavaScript est inutile.

Harry : Si le serveur fait son travail correctement et qu'il envoie, envoie, envoie, envoie, envoie, alors il ira plus vite. Et puis vous avez les avantages indirects de votre stratégie de mise en cache qui peut être plus granulaire. Donc, vraiment ennuyeux, vous mettriez à jour la taille de la police sur votre widget de sélection de date. Dans le monde H1, vous devez mettre en cache peut-être 200 kilowatts du large CSS de votre site. Alors que maintenant, vous venez de mettre en cache bust datepicker.css. Nous avons donc des avantages secondaires comme celui-là, qui sont certainement très précieux.

Drew : Je suppose que, dans le scénario où, comme par magie, vous receviez toutes vos requêtes en même temps, cela aurait évidemment pour effet d'enliser le client, n'est-ce pas ?

Harry : Ouais, potentiellement. Et ensuite, ce qui se passerait réellement, c'est que le client devrait faire une charge de planification des ressources, donc vous vous retrouveriez avec une cascade où toutes vos réponses reviennent en même temps, alors vous auriez un écart assez important entre le dernière réponse arrivée et sa capacité à s'exécuter. Donc, idéalement, lorsque nous parlons de JavaScript, vous voudriez que le navigateur les demande tous dans l'ordre de la demande, essentiellement l'ordre dans lequel vous les avez définis, le serveur pour les renvoyer tous dans le bon ordre afin que le navigateur puisse s'exécuter les dans le bon ordre. Parce que, comme vous le dites, s'ils sont tous revenus en même temps, vous avez juste un énorme JavaScript à exécuter en même temps, mais il doit encore être programmé. Vous pourriez donc avoir jusqu'à une seconde entre l'arrivée d'un fichier et son utilité. Donc, en fait, H1… Je suppose que, idéalement, ce que vous recherchez, c'est la planification des demandes H2, les réponses de style H1, afin que les choses puissent être rendues utiles au fur et à mesure qu'elles arrivent.

Drew : Donc, vous recherchez essentiellement une cascade de réponse qui semble pouvoir être descendue à ski.

Harry : Ouais, exactement.

Drew : Mais vous n'auriez pas besoin d'un parachute.

Harry : Ouais. Et c'est vraiment difficile… Je pense que le dire à haute voix semble vraiment trivial, mais étant donné la façon dont H2 a été vendu, je trouve ça assez… pas difficile parce que ça rend mon client… idiot… mais c'est une sacrée chose à expliquer pour eux… si vous pensez au fonctionnement de H1, ce n'était pas si mal. Et si nous obtenons des réponses qui ressemblent à ça et "Oh ouais, je peux le voir maintenant". J'ai déjà dû enseigner cela à des ingénieurs de performance. Des gens qui font ce que je fais. J'ai dû apprendre aux ingénieurs de performance que nous ne nous soucions pas trop du moment où les demandes sont faites, nous nous soucions vraiment du moment où les réponses deviennent utiles.

Drew : L'une des raisons pour lesquelles les choses semblent évoluer assez rapidement, en particulier au cours des cinq dernières années, est que les performances sont un sujet important pour Google. Et lorsque Google met du poids derrière quelque chose comme ça, cela gagne du terrain. Cependant, la performance est essentiellement un aspect de l'expérience utilisateur, n'est-ce pas ?

Harry : Oh, je veux dire… c'est un très bon podcast, j'y pensais il y a une demi-heure, je vous promets que j'y pensais il y a une demi-heure. La performance est l'accessibilité appliquée. Vous garantissez ou augmentez les chances que quelqu'un puisse accéder à votre contenu et je pense que l'accessibilité est toujours juste… Oh, ce sont des lecteurs d'écran, n'est-ce pas ? Ce sont des gens sans vue. Les décisions de créer un site Web plutôt qu'une application… les décisions sont d'accéder davantage à un public. Alors oui, la performance c'est l'accessibilité appliquée, qui est donc l'expérience utilisateur. Et cette expérience utilisateur pourrait se résumer à "Est-ce que quelqu'un pourrait même découvrir votre site" point final. Ou cela pourrait être « Cette expérience était-elle délicieuse ? Lorsque j'ai cliqué sur un bouton, a-t-il répondu en temps opportun ? » Je suis donc d'accord à 100 % et je pense que c'est en grande partie la raison pour laquelle Google y accorde du poids, c'est parce que cela affecte l'expérience utilisateur et si quelqu'un va faire confiance aux résultats de recherche, nous voulons essayer de donner à cette personne un site qui ils ne vont pas détester.

Drew : Et c'est… tout ce à quoi vous pensez, tous les avantages auxquels vous pensez, l'expérience utilisateur, des choses comme un engagement accru, c'est définitivement vrai, n'est-ce pas ? Il n'y a rien qui éloigne l'utilisateur d'un site plus rapidement qu'une expérience lente. C'est tellement frustrant, n'est-ce pas ? Utiliser un site où vous savez que la navigation n'est peut-être pas si claire et si vous cliquez sur un lien et que vous pensez « Est-ce ce que je veux ? N'est-ce pas?" Et juste le coût de faire ce clic, juste attendre, et puis vous devez cliquer sur le bouton de retour et puis cette attente, et c'est juste… vous abandonnez.

Harry : Ouais, et c'est logique. Si vous deviez aller au supermarché et que vous voyez qu'il est complètement bondé de monde, vous ferez le strict minimum. Vous n'allez pas dépenser beaucoup d'argent là-bas, c'est comme "Oh, j'ai juste besoin de lait", à l'intérieur et à l'extérieur. Alors que si c'est une belle expérience, vous avez « Oh, eh bien, pendant que je suis ici, je vais voir si… Oh, ouais ils ont ça… Oh, je cuisinerai ça demain soir » ou quoi que ce soit. Je pense que, trois décennies après le début du Web, même les gens qui construisent pour le Web luttent, parce que c'est intangible. Ils ont du mal à vraiment penser que ce qui vous ennuierait dans un vrai magasin vous ennuierait en ligne, et c'est le cas, et les statistiques montrent que c'est le cas.

Drew: Je pense qu'au tout début, je pense à la fin des années 90, montrant mon âge ici, lorsque nous créions des sites Web, nous pensions beaucoup à la performance, mais nous pensions à la performance d'un point de vue que les connexions que les gens étaient l'utilisation était si lente. Nous parlons d'accès à distance, de modems, de lignes téléphoniques, de modems 28K, 56K, et il y avait une tendance à un moment donné avec des images de style que toutes les autres lignes de l'image effaceraient avec une couleur unie pour donner ceci... si vous pouvez l'imaginer comme regarder l'image à travers un store vénitien. Et nous l'avons fait parce que cela aidait à la compression. Parce que toutes les autres lignes, l'algorithme de compression pourrait-

Harry : Réduire en un seul pointeur.

Drew : Ouais. Et donc vous avez considérablement réduit la taille de votre image tout en étant toujours capable d'obtenir… Et c'est devenu un élément de design. Tout le monde le faisait. Je pense que Jeffrey Zeldman a peut-être été l'un des premiers à avoir lancé cette approche. Mais ce à quoi nous pensions là-bas, c'était principalement la rapidité avec laquelle nous pourrions faire avancer les choses. Pas pour l'expérience utilisateur, parce que nous ne pensions pas à… Je veux dire, je suppose que c'était l'expérience utilisateur parce que nous ne voulions pas que les gens quittent nos sites, essentiellement. Mais nous pensions ne pas optimiser les choses pour qu'elles soient vraiment rapides, mais essayer d'éviter qu'elles ne soient vraiment lentes, si cela a du sens.

Harry : Ouais, ouais.

Drew : Et puis, je pense que lorsque les vitesses comme les lignes ADSL sont devenues plus répandues, nous avons cessé de penser en ces termes et avons commencé à ne plus y penser du tout. Et maintenant, nous sommes dans la situation où nous utilisons des appareils mobiles et ils ont des connexions limitées et peut-être des processeurs plus lents et nous devons y réfléchir à nouveau, mais cette fois en termes d'obtention d'un avantage. En plus de l'expérience utilisateur, cela peut avoir de réels avantages commerciaux en termes de coûts et de capacité à réaliser des bénéfices. N'est-ce pas?

Harry : Ouais, énormément. Je veux dire, je ne sais pas comment le formuler. Je ne me tire pas une balle dans le pied ici, mais une chose que j'essaie d'insister auprès des clients est que la vitesse du site va vous donner un avantage concurrentiel, mais ce n'est qu'une chose qui pourrait vous donner un avantage concurrentiel. Si vous avez un produit que personne ne veut acheter, peu importe la rapidité de votre site. Et de même, si quelqu'un veut vraiment le site Web le plus rapide au monde, vous devez supprimer vos images, supprimer votre CSS, supprimer votre JavaScript, puis voir combien de produits vous dites, car je vous garantis que la vitesse du site n'était pas le facteur. Mais des études ont montré qu'il y a d'énormes avantages à être rapide, de l'ordre de millions. Je travaille avec un client en ce moment même. Nous avons calculé pour eux que s'ils pouvaient rendre une page donnée une seconde plus vite, ou plutôt leur contenu le plus important pour la peinture était une seconde plus rapide, cela valait 1,8 million par an, ce qui est… c'est un grand nombre.

Drew : Cela paierait presque vos frais.

Harry : Hé ! Ouais, presque. Je leur ai dit : « Écoutez, après deux ans, tout sera payé. Vous atteindrez le seuil de rentabilité ». Je souhaite. Mais oui, est-ce que l'aspect client… désolé, l'aspect client de si vous avez un site E-Com, ils vont dépenser plus d'argent. Si vous êtes un éditeur, ils liront plus d'un article ou ils verront plus de minutes de contenu, ou quoi que vous fassiez, c'est votre KPI que vous mesurez. Cela pourrait être sur le site Smashing, il se pourrait qu'ils n'aient pas rebondi, ils ont en fait cliqué sur quelques articles supplémentaires parce que nous l'avons rendu vraiment facile et rapide. Et puis les sites plus rapides sont moins chers à gérer. Si vous avez trié votre stratégie de mise en cache, vous éloignerez les gens de vos serveurs. Si vous optimisez vos actifs, tout ce qui doit provenir de votre serveur pèsera beaucoup moins. Tellement moins cher à courir.

Harry : Le truc, c'est qu'il y a un coût pour s'y rendre. Je pense que Scott Jehl a probablement dit l'un des plus… Et je l'ai entendu de lui en premier, donc je vais supposer qu'il l'a inventé, mais le dicton est "Il est facile de créer un site Web rapide, mais il est difficile de créer un site Web vite". Et c'est tellement succinct. Parce que la raison pour laquelle les performances Web peuvent être repoussées dans la liste des choses à faire est que vous pourriez être en mesure de dire à un client "Si je rends votre site une seconde plus rapide, vous gagnerez 1,8 million de plus par an" ou cela peut être "Si vous venez d'ajouter Apple Pay à votre paiement, vous gagnerez cinq millions supplémentaires." Ce n'est donc pas qu'une question de perf web et ce n'est pas le facteur décisif, c'est une partie d'une stratégie beaucoup plus large, en particulier pour E-Com en ligne. Mais la preuve est que je l'ai mesuré de première main avec mes clients de détail, mes clients E-Com. Le cas est là, vous avez tout à fait raison. C'est un avantage concurrentiel, cela vous fera gagner plus d'argent.

Drew : À l'époque, encore une fois, je reviens à une époque révolue, mais des gens comme Steve Souders ont été parmi les premiers à vraiment commencer à écrire et à parler de performances Web. Et des gens comme Steve disaient essentiellement "Oubliez l'infrastructure backend, où tous les gains à obtenir sont dans le navigateur, dans le front-end, c'est là que tout se passe lentement." Est-ce toujours le cas 15 ans plus tard ?

Harry : Ouais, ouais. Il a refait le test entre l'époque et maintenant, et l'écart s'était en fait creusé, donc c'est en fait plus coûteux sur le fil. Mais il y a un contre-pied à cela, c'est-à-dire que si vous avez de très mauvaises performances en arrière-plan, si vous partez lentement, vous ne pouvez pas récupérer beaucoup plus sur le front-end. J'ai un client en ce moment, leur temps de premier octet est de 1,5 seconde. Nous ne pouvons donc jamais effectuer un rendu plus rapide que 1,5 seconde, donc ce sera un plafond. Nous pouvons toujours récupérer du temps sur le front-end, mais si vous avez un très, très mauvais moment pour le premier octet, vous avez des ralentissements du back-end, il y a une limite à la vitesse à laquelle vos efforts de performance front-end pourraient vous accélérer. Mais absolument.

Harry : C'est, cependant, en train de changer parce que… Eh bien, non ça ne change pas je suppose, ça empire. Nous poussons plus sur le client. Auparavant, il s'agissait de "Votre serveur est aussi rapide qu'il l'est, mais après cela, nous avons un tas de points d'interrogation." parce que j'entends ça tout le temps "Tous nos utilisateurs fonctionnent en WiFi. Ils ont tous des machines de bureau parce qu'ils travaillent tous depuis notre bureau. Eh bien, non, maintenant ils travaillent tous à domicile. Vous ne pouvez pas choisir. Donc, c'est là que viennent tous les points d'interrogation, c'est là que les ralentissements se produisent, où vous ne pouvez pas vraiment le contrôler. Après, le fait que maintenant on a tendance à miser davantage sur le client. J'entends par là des temps d'exécution entiers sur le client. Vous avez de toute façon déplacé toute votre logique d'application hors d'un serveur, donc votre temps au premier octet devrait être très, très minime. Il devrait s'agir d'envoyer des bundles d'un CDM à mon… mais vous êtes passé de la possibilité de spécifier vos propres serveurs à l'espoir que quelqu'un n'exécute pas Netflix sur la même machine sur laquelle il essaie de visualiser votre site Web. .

Drew : C'est un très bon point sur la façon dont nous concevons les sites et je pense que la meilleure pratique traditionnelle a toujours été d'essayer de prendre en charge toutes sortes de navigateurs, toutes sortes de vitesses de connexion, toutes sortes de tailles d'écran, car vous ne Je ne sais pas à quoi l'utilisateur va s'attendre. Et, comme vous l'avez dit, vous avez ces scénarios où les gens disent "Oh non, nous savons que tous nos utilisateurs sont sur leur ordinateur de bureau délivré par le travail, ils exécutent ce navigateur, c'est la dernière version, ils sont câblés dans le LAN" mais ensuite les choses arrivent. L'un des grands avantages d'avoir des applications Web est que nous pouvons faire des choses comme répartir soudainement notre main-d'œuvre chez eux et ils peuvent continuer à travailler, mais cela n'est vrai que si la qualité de l'ingénierie était telle qu'alors quelqu'un qui tourne sur leur machine domestique qui pourrait avoir IE11 dessus ou autre, que la qualité du travail soit là, cela signifie en fait que le Web réalise son potentiel en étant un média vraiment accessible.

Drew : Comme vous le dites, il y a cette tendance à transférer de plus en plus de choses dans le navigateur, et, bien sûr, si le navigateur est lent, c'est là que la lenteur se produit. Vous devez vous demander « Est-ce une bonne tendance ? Devrions-nous faire cela ? » J'ai un site auquel je pense particulièrement, j'ai remarqué qu'il est presque 100% rendu par le serveur. Il y a très peu de JavaScript et c'est rapide comme l'éclair. Chaque fois que j'y vais, je pense "Oh, c'est rapide, qui a écrit ça?" Et puis je me rends compte "Oh ouais, c'était moi".

Harry : C'est parce que vous êtes sur localhost, pas étonnant que cela semble rapide. C'est votre site de développement.

Drew : Ensuite, mon travail quotidien, nous construisons notre application d'une seule page et déplaçons des éléments du serveur parce que le serveur est le goulot d'étranglement dans ce cas. Pouvez-vous simplement dire qu'il est plus performant d'être dans le navigateur ? Ou plus performant pour être sur le serveur ? S'agit-il simplement de mesurer et de prendre au cas par cas?

Harry : Je pense que vous devez être très, très, très conscient de votre contexte et… sincèrement, je pense qu'une erreur est… le narcissisme où les gens pensent « Oh, mon blog mérite d'être affiché dans le navigateur de quelqu'un. Mon blog avec un taux de rebond de 89 % a besoin de son propre temps d'exécution dans le navigateur, car j'ai besoin que les navigations ultérieures soient rapides, je veux juste récupérer un… essentiellement un diff des données. » De toute façon, personne ne clique sur votre prochain article, mon pote, ne poussez pas un temps d'exécution dans le tuyau. Vous devez donc être très conscient de votre contexte.

Harry : Et je sais que… si Jeremy Keith écoute ça, il va probablement me lancer un coup, mais il y a, je dirais, une différence entre un site Web et une application Web et la définition de cela est très, très trouble. Mais si vous avez une application fortement en lecture et en écriture, donc quelque chose où vous saisissez des données, manipulez des données, etc. Fondamentalement, mon site n'est pas une application Web, c'est un site Web, il est en lecture seule, que je mettrais fermement dans le camp du site Web. Quelque chose comme mon logiciel de comptabilité est une application Web, je dirais que c'est une application Web et je suis prêt à subir un peu de temps de démarrage, car je sais que je serai là pendant 20 minutes, une heure, peu importe. Donc, vous avez besoin d'un peu de contexte, et encore une fois, peut-être que le narcissisme est un peu dur, mais vous devez avoir un vrai "Avons-nous besoin de faire de ce journal une application côté client?" Non, vous ne le faites pas. Non, vous ne le faites pas. Les gens ont un bloqueur de publicités, les gens n'aiment pas les sites de journaux de banlieue de toute façon. Ils ne vont probablement même pas lire l'article et en parler sur Facebook. Ne construisez pas quelque chose comme ça en tant qu'application rendue par le client, ce n'est pas approprié.

Harry : Je pense donc qu'il y a définitivement un moment où il serait utile de se concentrer davantage sur le client, et c'est à ce moment-là que vous êtes moins sensible au désabonnement. Donc n'importe quel type de com, par exemple, je fais un audit un moment pour un site qui… je pense que c'est un site E-Com mais c'est 100% sur le client. Vous désactivez JavaScript et vous ne voyez rien, juste un div vide id="app". E-Com c'est… vous êtes très sensible à tout problème. Votre flux de paiement est même subtilement erroné, je pars ailleurs. C'est trop lent, je pars ailleurs. Vous n'avez pas le contexte où quelqu'un est prêt à se coucher dans cette application pendant un certain temps.

Harry : Photoshop. J'ouvre Photoshop et je suis assez heureux de savoir que cela va prendre 45 secondes d'écran de démarrage parce que je vais y rester pendant… en gros, les 45 secondes valent les 45 minutes. Et c'est si difficile à définir, c'est pourquoi j'ai vraiment du mal à convaincre les clients "S'il vous plaît ne faites pas ça" parce que je ne peux pas simplement dire "Combien de temps pensez-vous que votre utilisateur va être là". Et vous pouvez le rapprocher de… si votre taux de rebond de 89 % n'est pas optimisé pour une deuxième page vue. Commencez par réduire ce taux de rebond. Je pense qu'il y a certainement une scission, mais ce que je dirais, c'est que la plupart des gens tombent du mauvais côté de cette ligne. La plupart des gens mettent des choses dans le client qui ne devraient pas y être. CNN, par exemple, vous ne pouvez pas lire un seul titre sur le site Web de CNN tant qu'il n'a pas complètement démarré une application JavaScript. La seule chose que le serveur rend est l'en-tête et le pied de page qui sont la seule chose dont les gens ne se soucient pas.

Harry : Et j'ai l'impression que c'est juste... Je ne sais pas comment on arrive à ce point. Ce ne sera jamais la meilleure option. Vous livrez une page qui est effectivement inutile et qui doit ensuite dire "Cool, je vais chercher ce qui aurait été une application Web mais nous allons l'exécuter dans le navigateur, puis je vais demander un titre , alors vous pouvez commencer à… oh, vous êtes parti. Ça m'énerve vraiment, vraiment.

Harry : Et ce n'est la faute de personne, je pense que c'est le début de ce genre d'écosystème JavaScript, le battage médiatique autour de lui, et aussi, cela va sembler vraiment dur mais… C'est fondamentalement beaucoup d'implémentation naïve. Bien sûr, Facebook a inventé React et peu importe, cela fonctionne pour eux. Neuf fois sur 10, vous ne travaillez pas à l'échelle de Facebook, 95 fois sur 100, vous n'êtes probablement pas les ingénieurs Facebook les plus intelligents, et c'est vraiment, vraiment cruel et cela semble horrible à dire, mais vous ne pouvez qu'obtenir… Aucun de ces choses sont rapides par défaut. Vous avez besoin d'une implémentation très, très élégante de ces choses pour les rendre correctes.

Harry : J'avais cette discussion avec mon ancien… il était ingénieur en chef de l'équipe dans laquelle j'étais il y a 10 ans chez Sky. Je lui en parlais l'autre jour et il a dû travailler très dur pour rendre rapidement une application rendue par un client, alors que pour rendre une application rendue par un serveur rapide, vous n'avez rien à faire. Vous avez juste besoin de ne pas ralentir à nouveau. Et j'ai l'impression qu'il y a beaucoup de lunettes teintées de rose, de naïveté, de marketing… J'ai l'air si sombre, nous devons passer à autre chose avant que je ne commence vraiment à perdre des gens ici.

Drew : Pensez-vous que nous avons tendance, en tant qu'industrie, à nous concentrer davantage sur l'expérience des développeurs que sur l'expérience des utilisateurs ?

Harry : Pas dans son ensemble, mais je pense que ce problème surgit à un endroit auquel on s'attendrait. Si vous regardez la disparité… Je ne sais pas si vous avez vu cela, mais je suppose que vous avez, vous semblez vraiment avoir le doigt sur le pouls, la disparité entre les données de l'archive HTTP sur les frameworks et Les bibliothèques JavaScript sont utilisées dans la nature par rapport à l'enquête sur l'état de JavaScript, si vous suivez l'enquête sur l'état de JavaScript, cela indiquerait "Oh oui, 75% des développeurs utilisent React" alors que moins de 5% des sites utilisent React. Donc, j'ai l'impression que, en masse, je ne pense pas que ce soit un problème, mais je pense que dans les domaines auxquels vous vous attendez, une grande fidélité à un framework par exemple, l'expérience des développeurs est… évangélisée probablement avant l'utilisateur. Je ne pense pas qu'il faille négliger l'expérience des développeurs, je veux dire, tout a un coût de maintenance. Ta voiture. Il y a eu une décision lors de sa conception : "Eh bien, si nous cachons cette clé, cette fonctionnalité, à un mécanicien, cela prendra beaucoup plus de temps à ce mécanicien pour la réparer, donc nous ne faisons pas des choses comme ça". Il doit donc y avoir un équilibre entre l'ergonomie et la convivialité, je pense que c'est important. Je pense que se concentrer principalement sur l'expérience des développeurs est tout simplement déconcertant pour moi. N'optimisez pas pour vous, optimisez pour votre client, votre client vous paie, ce n'est pas l'inverse.

Drew : Donc la chambre d'écho en ligne n'est pas exactement représentative de la réalité quand vous voyez tout le monde dire « Oh, vous devriez utiliser ceci, vous devriez faire cela », alors ce n'est en fait qu'un très petit pourcentage de personnes.

Harry : Exact, et c'est tant mieux, c'est rassurant. La chambre d'écho… ce n'est peut-être pas sain d'avoir ce genre de monoculture, si vous voulez l'appeler ainsi. Mais aussi, j'ai l'impression que… et je l'ai vu dans beaucoup de mes propres travaux, beaucoup de développeurs… En tant que consultant, je travaille avec beaucoup d'entreprises différentes. Beaucoup de gens font un travail incroyable dans WordPress. Et WordPress alimente 24 % du Web. Et j'ai l'impression qu'il pourrait être assez facile pour un développeur comme celui-ci travaillant dans quelque chose comme WordPress ou PHP sur le backend, du code personnalisé, quoi qu'il en soit, de se sentir un peu comme "Oh, je suppose que tout le monde utilise React et nous ne sommes pas ” mais en fait, non. Tout le monde parle de React mais vous suivez toujours le courant, vous êtes toujours majoritaire. C'est assez rassurant de retrouver la majorité silencieuse.

Drew : La tendance vers les générateurs de sites statiques, puis l'hébergement de sites entièrement sur un CDN, une sorte d'approche JAMstack, je suppose que lorsque nous parlons de ces types de sites de type publication, plutôt que de sites de type logiciel, je suppose que c'est une tendance vraiment saine , pensez-vous?

Harry : J'adore ça, absolument. Vous vous souvenez quand nous avions l'habitude d'appeler SSG "fichier volet", n'est-ce pas ?

Drew : Ouais.

Harry : Donc, j'ai construit CSS Wizardry sur Jekyll à l'époque où Jekyll s'appelait un site Web de fichiers à rabat. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Drew : Ouais.

Harry: … diminishing returns, that's exactly it. Oui exactement.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? C'est tellement bon. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry : Il imposait le respect mais c'était l'un des gars, nous l'aimions tous beaucoup. Mais il était massif dans toutes les dimensions. Bien plus de six pieds de haut, mais juste un grand garçon. Grand, grand, grand, grand homme. Et il nous a dit "Si vous deviez concevoir une porte, la concevriez-vous pour la personne moyenne?" Et les cerveaux de 15 ans disent "Eh bien ouais, si tout le monde mesure environ 5'9 alors ouais" Il était comme "Eh bien, immédiatement, Harry ne peut pas utiliser cette porte." Vous ne concevez pas pour la personne moyenne, vous concevez pour les extrémités parce que vous voulez que cela soit utile au plus grand nombre. Si vous avez conçu une chaise pour la personne moyenne, M. Brocklesby n'allait pas s'y adapter. Alors il m'a appris à partir d'un très, très grand âge, le design jusqu'aux extrémités.

Harry : Et là où cela devient vraiment intéressant dans les performances Web, c'est… Si vous imaginez une échelle, et que vous prenez l'échelle par le bot… D'accord, je viens de réaliser que ma métaphore pourrait… Je vais m'y tenir et vous pourrez rire de moi après. Imaginez une échelle et vous soulevez l'échelle par les échelons inférieurs. Et ce sont vos pires expériences. Vous choisissez le barreau inférieur de l'échelle pour le soulever. Toute l'échelle vient avec, comme une marée montante fait flotter tous les bateaux. La raison pour laquelle la métaphore ne fonctionne pas est que si vous prenez une échelle par le barreau supérieur, tout se soulève également, c'est une échelle. Et la métaphore ne fonctionne même pas si je la transforme en échelle de corde, parce qu'une échelle de corde alors, vous soulevez l'échelon inférieur et rien ne se passe mais… mon point est que si vous pouvez améliorer l'expérience pour votre 90e centile, il faut obtenez cela pour votre 10e centile, non ?

Harry : Et c'est pourquoi je dis aux clients qu'ils me disent des choses comme « Oh, la plupart de nos utilisateurs sont en 4G sur iPhone », alors d'accord, d'accord, et nous commençons à tester la 3G sur Android, comme « Non, non, la plupart de nos utilisateurs sont des iPhones » d'accord… cela signifie que votre utilisateur moyen aura une meilleure expérience, mais toute personne qui n'est pas déjà dans le 50e centile est simplement laissée pour compte. Alors placez la barre assez haute pour vous-même en fixant des attentes assez basses.

Harry : Désolé, j'ai la très mauvaise habitude de donner des réponses très longues à des questions courtes. Mais c'était une question fantastique et, pour essayer de conclure, je suis à 100% d'accord avec vous que vous voulez regarder cette longue traîne, vous voulez regarder ça… votre 80e centile parce que si vous prenez toutes les expériences sur le site et regardez la médiane, et vous améliorez la médiane, cela signifie que vous l'avez encore amélioré pour les personnes qui étaient déjà assez satisfaites. 50% des personnes étant effectivement ignorées n'est pas la bonne approche. Et ouais, ça revient toujours à M. Brocklesby qui me dit "Ne concevez pas pour la personne moyenne parce qu'alors Harry ne peut pas utiliser la porte". Oh, pour tous ceux qui écoutent, je mesure 193 centimètres, donc je suis assez dégingandé, c'est ce que c'est.

Drew : Et tous ces bras et ces jambes.

Harry : Ouais. Voici un autre bon aussi. Ma copine a récemment découvert les paramètres d'accessibilité dans iOS… donc tout le monde a son téléphone en mode silencieux, n'est-ce pas ? Personne n'a vraiment de téléphone qui sonne, tout le monde l'a en mode silencieux. Elle a trouvé que "Oh vous savez, vous pouvez le régler pour que lorsque vous recevez un message, le flash clignote. Et si vous appuyez deux fois sur le dos du téléphone, cela fera une capture d'écran. Et ce sont des paramètres d'accessibilité, ils sont conçus pour ce 95e centile. Pourtant, elle est comme "Oh, c'est vraiment utile".

Harry : Pareil avec OXO Good Grips. OXO Good Grips, les ustensiles de cuisine. J'en ai plein dans la cuisine. Ils sont conçus parce que la femme du fondateur souffrait d'arthrite et qu'il souhaitait fabriquer des ustensiles plus confortables. Il a conçu pour le 99e centile, la plupart des gens n'ont pas d'arthrite. Mais en concevant pour le 99e centile, par inadvertance, tout le monde se dit "Oh mon Dieu, pourquoi tous les éplucheurs de pommes de terre ne peuvent-ils pas être aussi confortables?" Et j'ai l'impression que c'est vraiment, vraiment… J'aime une sensation de bien-être ou une anecdote que j'aime raconter dans ce genre de scénarios. Mais oui, si vous optimisez pour eux… Eh bien, une marée montante fait flotter tous les bateaux et cela optimise donc la queue des gens et vous allez capturer beaucoup de clients encore plus heureux en plus.

Drew : Avez-vous le fouet manuel OXO Good Grips ?

Harry : Je ne sais pas. Je ne sais pas, c'est bon ?

Drew : Regardez-le. C'est si bon.

Harry : J'ai la trancheuse à mandoline OXO Good Grips qui m'a enlevé le bout du doigt la semaine dernière.

Drew : Ouais, je ne m'approcherai pas de l'un d'entre eux.

Harry : Ouais, c'est ma stupide faute.

Drew : Un autre exemple de ma propre expérience avec la restauration de cette longue traîne est que, dans le projet sur lequel je travaille en ce moment, cette longue traîne est juste à la fin, vous avez des gens avec les performances les plus lentes, mais s'il s'avère que si vous regardez qui sont ces clients, ce sont les clients les plus précieux pour l'entreprise-

Harry : D'accord.

Drew : … parce que ce sont les plus grandes organisations avec le plus de données.

Harry : D'accord.

Drew : Et donc ils rencontrent des goulots d'étranglement parce qu'ils ont tellement de données à afficher sur une page et ces pages doivent être un peu refactorisées pour aider ce cas d'utilisation. Ils ont donc l'expérience la plus lente et, en fin de compte, ils paient le plus d'argent et font beaucoup plus de différence que toutes les personnes ayant une expérience très rapide parce qu'ils sont des utilisateurs gratuits avec un petite quantité de données et tout fonctionne bien et c'est rapide.

Harry : C'est une dimension fascinante, n'est-ce pas ? En fait, j'ai eu une situation similaire… Je n'avais pas l'impact commercial que vous venez de décrire, mais j'ai travaillé avec un client il y a quelques années et son PDG m'a contacté parce que son site était lent. Genre, lent, lent, lent. Un gars vraiment sympa aussi, c'est juste un gars vraiment sympa, mais il est encadré, comme un vrai riche. Et il a le dernier iPhone, il peut se le permettre. C'est un multimillionnaire, il passe une grande partie de son temps à voler entre l'Australie, d'où il est originaire, et l'Estonie, où il est désormais basé.

Harry : Et il vole en première classe, bien sûr. Mais cela signifie que la plupart de son temps sur son bel iPhone 12 Pro Max brillant, peu importe, est sur le WiFi de l'avion, ce qui est terrible. Et c'était cette juxtaposition vraiment incroyable où il possède le site et il l'utilise beaucoup, c'est un site qu'il utilise. Et il le poussait… Je veux dire facilement que leur client le plus riche était leur PDG. Et il est dans cette position étrangement privilégiée où il est sur une connexion pire que Joe Public parce qu'il est quelque part au-dessus de Singapour sur un vol Quantas en train de se faire verser du champagne dans le cou, et il se débat. Et c'était une idée vraiment fascinante qui… Oh oui, parce que vous avez votre 95e centile, vous pouvez essentiellement aller dans les deux sens.

Drew : Oui, c'est lorsque vous commencez à optimiser l'utilisation d'un site avec une coupe de champagne à la main que vous pensez : "Peut-être que nous commençons à perdre un peu le chemin".

Harry : Ouais, exactement.

Drew : Nous avons parlé un peu de la mesure de la performance, et d'après ma propre expérience avec le travail de performance, il est vraiment essentiel de mesurer tout.g A pour que vous puissiez identifier où se trouvent les problèmes, mais B pour que lorsque vous commencez réellement à vous attaquer à quelque chose, vous puissiez dire si vous faites une différence et quelle différence vous faites. Comment procéder pour mesurer la performance de nos sites ? Quels outils pouvons-nous utiliser et par où commencer ?

Harry : Oh mec, une autre excellente question. Il existe donc une gamme de réponses en fonction du temps, des ressources et de l'inclinaison à fixer la vitesse du site. Donc, ce que je vais essayer de faire avec le client, c'est… Certaines mesures standard sont vraiment bonnes. Temps de chargement, ne vous en souciez plus. C'est très, très, très… je veux dire, c'est un bon proxy si votre temps de chargement est de 120 secondes, je suppose que vous n'avez pas un site Web très rapide, mais c'est trop obscur et ce n'est pas vraiment orienté client. En fait, je pense que les éléments vitaux sont un très bon pas dans la bonne direction, car ils mesurent l'expérience utilisateur, mais ils sont basés sur des informations techniques. La plus grande peinture de contenu est une très bonne chose à voir, mais les éléments techniques permettent de débloquer votre chemin critique, assurez-vous que les images de héros arrivent rapidement et assurez-vous que votre stratégie de polices Web est correcte. Il y a un courant technique sous-jacent à ces métriques. Ce sont vraiment bien sur l'étagère.

Harry : Cependant, si les clients ont le temps, c'est généralement le temps, car vous voulez capturer les données, mais vous avez besoin de temps pour réellement capturer les données. Donc, ce que j'essaie de faire avec les clients, c'est d'y aller : « Écoutez, nous ne pouvons pas travailler ensemble pendant les trois prochains mois parce que je suis complet. Donc, ce que nous pouvons faire, c'est vous configurer très rapidement avec un essai gratuit de Speedcurve, mettre en place des métriques personnalisées ", ce qui signifie que pour un client éditeur, un journal, je mesurerais" À quelle vitesse a été le titre du article rendu ? À quelle vitesse l'image principale de l'article a-t-elle été rendue ? » Pour un client de commerce électronique, je veux mesurer, car évidemment, vous mesurez des choses comme démarrer le rendu passivement. Dès que vous commencez à utiliser un logiciel de surveillance des performances, vous capturez gratuitement vos mesures de performances réelles. Donc, votre première peinture de contenu, votre plus grand contenu, etc. Ce que je veux vraiment capturer, ce sont les choses qui comptent pour eux en tant qu'entreprise.

Harry : Donc, travailler avec un client E-Com au moment où nous sommes en mesure de corréler… Plus votre rendu de démarrage est rapide, quelle est la probabilité d'un ajout au panier. Si vous pouvez leur montrer un produit plus tôt, ils sont plus susceptibles de l'acheter. Et c'est beaucoup d'efforts à mettre en place, c'est une sorte d'objectif ambitieux pour les clients qui sont vraiment ambitieux, mais tout ce que vous voulez vraiment mesurer, car comme je l'ai dit, vous ne voulez pas vraiment mesurer ce que votre plus grand Contentful Paint, vous voulez mesurer vos revenus et cela a-t-il été influencé par Large Contentful Paint ? Donc, l'objectif ultime, la chose ultime, serait tout ce que vous verriez comme un KPI pour cette entreprise. Cela pourrait être, dans les journaux, jusqu'où quelqu'un a-t-il fait défiler l'article ? Et cela est-il corrélé de quelque manière que ce soit au premier délai d'entrée? Les gens ont-ils lu plus d'articles si le CLS était inférieur ? Mais avant de commencer à créer des métriques personnalisées, je pense honnêtement que Web Vitals est un très bon point de départ et qu'il a également été assez bien normalisé. Ça devient un… Je ne sais pas quel est le mot. Le plus petit dénominateur commun, je suppose, où tout le monde dans l'industrie peut désormais discuter des performances sur ce terrain de jeu égal.

Harry : Un problème que j'ai, et je dois en fait organiser une réunion avec l'équipe des données vitales, c'est que je pense aussi vraiment que Lighthouse est génial, mais CLS représente 33 % des données vitales Web. Vous avez LCP, FID, CLS. CLS est de 33% de vos signes vitaux. Vitals est ce qui se passe normalement devant votre équipe marketing, votre service d'analyse, car il apparaît dans la console de recherche, il est mentionné dans le contexte des pages de résultats de recherche, alors que Vitals est concerné, vous avez une pondération importante, 33 %, un tiers des signes vitaux est CLS, ce n'est que 5% de notre score Lighthouse. Donc, ce que vous allez obtenir, ce sont des développeurs qui construisent autour de Lighthouse, car il peut être intégré à l'outillage, c'est une métrique de laboratoire. Les signes vitaux sont des données de terrain, c'est du rhum.

Harry : Vous avez donc cette énorme déconnexion où votre équipe marketing dit "CLS est vraiment mauvais" et les développeurs pensent "Eh bien, c'est 5% du score Lighthouse que DevTools me donne, c'est 5% du score que Lighthouse CLI nous donne dans CircleCI "ou tout ce que vous utilisez, mais pour l'équipe marketing, c'est 33 % de ce qui les intéresse. Donc, le problème, il y a un peu de décalage parce que je pense que Lighthouse est très précieux, mais je ne sais pas comment ils réconcilient cette différence assez massive où, dans les signes vitaux, CLS est à 33% de votre score… eh bien, pas score parce que vous n'en ont pas vraiment, et Lighthouse n'est que de 5%, et ce sont des choses comme ça qui doivent encore être réglées avant que nous puissions rendre cette discussion transparente.

Harry : Mais, encore une fois, longue réponse à une courte question. Vitals est vraiment bon. LCP est une bonne métrique d'expérience utilisateur qui peut se résumer à des solutions techniques, comme c'est le cas avec CLS. Je pense donc que c'est un très bon point de départ. Au-delà de cela, ce sont des métriques personnalisées. Ce que j'essaie d'amener mes clients à faire, c'est un point où ils ne se soucient pas vraiment de la vitesse de leur site, ils se soucient juste de gagner plus d'argent depuis hier, et si c'était le cas, c'est parce qu'il fonctionnait vite ? S'il faisait moins c'est parce qu'il tournait moins vite ? Je ne veux pas qu'ils chassent un LCP mystique de deux secondes, je veux qu'ils chassent le LCP optimal. Et si cela s'avère en fait être plus lent que ce que vous pensez, alors peu importe, c'est bien.

Drew : Donc, pour le développeur Web qui s'intéresse simplement à… il n'a pas de budget à dépenser pour des outils comme Speedcurve et autres, il peut évidemment exécuter des outils comme Lighthouse uniquement dans son navigateur, pour obtenir une bonne mesure… Est-ce que des choses comme Google Analytique utile pour ce niveau ?

Harry : Ils le sont et ils peuvent être rendus plus utiles. Analytics, depuis de nombreuses années maintenant, a capturé des informations de performance rudimentaires. Et ce sera le temps DNS, TCP et TLS, le temps du premier octet, le temps de téléchargement de la page, qui est un proxy… eh bien, peu importe, juste le temps de téléchargement de la page et le temps de chargement. Donc des métriques assez maladroites. Mais c'est un bon point de départ et normalement, chaque projet que je commence avec un client, s'il n'a pas New Relic ou Speedcurve ou quoi que ce soit, je dirai simplement "Eh bien, laissez-moi jeter un œil à vos analyses" parce que je peux à moins proxy la situation à partir de là. Et ça ne sera jamais aussi bon que quelque chose comme Speedcurve ou New Relic ou Dynatrace ou autre. Vous pouvez envoyer des métriques personnalisées vraiment, vraiment, très facilement à l'analyse. Si quelqu'un qui écoute veut pouvoir envoyer… mon site par exemple. J'ai des métriques comme "À quelle vitesse pouvez-vous lire le titre d'un de mes articles ? À quel moment l'image de la page À propos a-t-elle été affichée ? À quel moment a été l'appel à l'action qui vous implore de m'engager ? Combien de temps est-ce rendu à l'écran? Vraiment trivial pour capturer ces données et presque aussi trivial pour les envoyer à l'analyse. Donc, si quelqu'un veut voir la source sur mon site, faites défiler jusqu'à la balise de fermeture du corps et trouvez l'extrait d'analyse, vous verrez à quel point il est facile pour moi de capturer des données personnalisées et de les envoyer à l'analyse. Et, dans l'interface utilisateur d'analyse, vous n'avez rien à faire. Normalement, vous devez configurer des rapports personnalisés, extraire les données et les rendre présentables. Ce sont des citoyens de première classe dans Google Analytics. Ainsi, dès que vous commencez à capturer des analyses personnalisées, une section entière du tableau de bord lui est dédiée. Il n'y a pas de configuration, pas de travail lourd dans GA lui-même, donc c'est vraiment trivial et, si les clients ont un vrai budget ou peut-être que je veux leur montrer la puissance de la surveillance personnalisée, je ne veux pas dire "Oh ouais, je promets ça va être vraiment bien, puis-je juste avoir 24 000 000 pour Speedcurve ? » Je peux commencer par dire simplement « Écoutez, c'est rudimentaire. Voyons les possibilités ici, maintenant nous pouvons peut-être vous convaincre de passer à quelque chose comme Speedcurve.

Drew : J'ai souvent constaté que mon instinct vis-à-vis de la vitesse à laquelle quelque chose devrait être, ou de l'impact qu'un changement devrait avoir, peut être erroné. Je vais faire un changement et penser que je rends les choses plus rapides, puis je le mesure et en fait, j'ai rendu les choses plus lentes. Est-ce que c'est juste que je suis nul à la perf Web ?

Harry : Pas du tout. J'ai un exemple très pertinent de cela. Préchargement… une véritable introduction rapide pour tous ceux qui n'ont pas entendu parler de préchargement, le chargement de certains actifs sur le Web est intrinsèquement très lent et les deux principaux candidats ici sont des images d'arrière-plan en CSS et des polices Web, car avant de pouvoir télécharger une image d'arrière-plan, vous avez pour télécharger le HTML, qui télécharge ensuite le CSS, puis le CSS dit "Oh, cette div sur la page d'accueil a besoin de cette image d'arrière-plan." C'est donc intrinsèquement très lent parce que vous avez tout ce temps CSS entre les deux. Avec le préchargement, vous pouvez mettre une ligne en HTML dans la balise head qui dit "Hé, vous ne le savez pas encore mais, croyez-moi, vous aurez besoin de cette image très, vraiment, très bientôt." Vous pouvez donc mettre un préchargement dans le HTML qui déclenche ce téléchargement de manière préventive. Au moment où le CSS a besoin de l'image d'arrière-plan, c'est comme "Oh cool, nous l'avons déjà, c'est rapide." Et c'est présenté comme ce messie de perf Web… Voici la chose, et je vous promets, j'ai tweeté cela la semaine dernière et j'ai eu raison deux fois depuis. Les gens entendent parler de préchargement, et de la promesse qu'il donne, et aussi il est très fortement poussé par Lighthouse, en théorie, cela rend votre site plus rapide. Les gens sont tellement attachés à l'idée de la précharge que même si je peux prouver que cela ne fonctionne pas, ils ne la supprimeront plus. Parce que "Non, mais Phare a dit." Maintenant, c'est l'une de ces choses où la théorie est solide. Si vous devez attendre votre police Web, au lieu de la télécharger plus tôt, vous verrez les choses plus rapidement. Le problème est que, lorsque vous pensez au fonctionnement réel du Web, toute page que vous visitez en premier, tout nouveau domaine que vous visitez, vous avez une quantité limitée de bande passante et le navigateur utilise très intelligemment cette bande passante correctement. Il parcourra votre code HTML très rapidement et dressera une liste de courses. La chose la plus importante est CSS, puis c'est ce jQuery, puis c'est ceci… et puis les prochaines choses sont celles-ci, celles-ci et celles-ci moins prioritaires. Dès que vous commencez à charger votre HTML avec des préchargements, vous dites au navigateur « Non, non, non, ce n'est plus ta liste de courses, mon pote, c'est la mienne. Vous devez aller les chercher. Cette quantité finie de bande passante est toujours finie, mais elle n'est pas dépensée sur plus d'actifs, donc tout devient légèrement plus lent. Et j'ai dû huer ça deux fois la semaine dernière, et les gens disent toujours "Ouais mais non, c'est parce que ça se télécharge plus tôt." Non, il est demandé plus tôt, mais il vole la bande passante de votre CSS. Vous pouvez littéralement voir que vos polices Web volent de la bande passante à votre CSS. C'est donc une de ces choses où vous devez, devez, devez suivre les chiffres. Je l'ai déjà fait sur un client à grande échelle. Si vous écoutez ceci, vous avez entendu parler de ce client, et j'ai insisté sur le fait que "Non, non, vos étiquettes de tête sont dans le mauvais ordre parce que c'est comme ça que ça devrait être et vous devez les avoir dans ce commande parce que théoriquement cela donne des indices là-dedans… » Même dans ce que j'étais pour le client, je savais que je me faisais passer pour un imbécile. En raison du fonctionnement des navigateurs, il doit être plus rapide. Donc je fais le stratagème, ce changement… à plusieurs millions de personnes, et ça a ralenti. C'est devenu plus lent. Et moi assis là, insistant avec indignation "Non mais, les navigateurs fonctionnent comme ça" est inutile parce que ça ne marche pas. Et nous l'avons annulé et je me suis dit "Désolé ! Je vais quand même vous facturer ça ! Donc ce n'est pas du tout toi.

Drew : Suivez ces chiffres.

Harry : Ouais, exactement. "En fait, je dois vous facturer plus, car j'ai passé du temps à revenir en arrière, ça m'a pris plus de temps." Mais ouais, tu as tout à fait raison, ce n'est pas toi, c'est une de ces choses où... Je l'ai fait un tas de fois à une échelle beaucoup plus petite, où je me dis "Eh bien, ça doit théoriquement marcher" et ça ne marche pas 't. Vous n'avez qu'à suivre ce qui se passe dans le monde réel. C'est pourquoi cette surveillance est vraiment importante.

Drew : À mesure que le paysage change et que la technologie évolue, Google déploie de nouvelles technologies qui nous aident à accélérer les choses. Existe-t-il un bon moyen de suivre les changements ? Existe-t-il des ressources que nous devrions rechercher pour maintenir nos compétences à jour en matière de performances Web ?

Harry : Pour aborder rapidement tout le "Google making"… Je sais que c'est un peu ironique mais je vais me concentrer là-dessus. Je suppose que vers le début, pariez sur le navigateur. Des choses comme AMP, par exemple, sont au mieux une solution après réflexion. Rien ne remplace la création d'un site rapide, et dès que vous commencez à utiliser des choses comme AMP, vous devez vous en tenir à ces normes non standard, à la merci de l'équipe AMP qui change d'avis. J'ai eu un client qui a dépensé une fortune sous licence pour une police d'un fournisseur de polices AMP autorisé, puis à un moment donné, AMP a décidé "Oh en fait non, cette police fournie, nous allons les bloquer maintenant". J'avais donc un client qui a beaucoup investi dans AMP et ce fournisseur de polices et a dû choisir "Eh bien, annulons-nous tout le travail AMP ou gaspillons-nous simplement ce très gros nombre par an sur la police Web" bla, bla, bla. Donc, je me méfierais de n'importe qui… Je suis un expert des développeurs Google mais je ne connais aucun bâillonnement… Je peux être critique, et je dirais… évitez les choses qui sont saluées comme une taille unique -solution universelle, des choses comme AMP.

Harry : Et pour jeter sur quelqu'un d'autre pendant une seconde, Cloudflare a une chose appelée Rocket Loader, qui est AMP-esque dans son effort. Il est conçu comme "Oh, activez simplement ce truc sur votre CDN, cela rendra votre site plus rapide." Et en fait, c'est juste un remplacement pour la construction de votre site correctement en premier lieu. Alors… pour aborder cet aspect, essayez de rester aussi indépendant que possible, sachez comment fonctionnent les navigateurs, ce qui signifie immédiatement que la monoculture de Chrome, vous êtes de retour sur les genoux de Google, mais sachez comment fonctionnent les navigateurs, respectez certaines idéologies fondamentales. Lorsque vous construisez un site, regardez la page. Que ce soit dans Figma, ou Sketch, ou n'importe où, regardez le design et dites "Eh bien, c'est ce qu'un utilisateur veut voir en premier, donc je ne mettrai rien en travers de cela. Je ne vais pas charger paresseusement cette image principale parce que c'est idiot, pourquoi ferais-je ça ? » Alors pensez simplement à "Que voudriez-vous que l'utilisateur soit en premier?" Sur un site E-Com, ce sera cette image de produit, probablement une navigation en même temps, mais les critiques du produit, Q et A du produit, la charge paresseuse. Mettez cela derrière JavaScript.

Harry : Certaines méthodes de travail fondamentales qui vous seront utiles, quelle que soit la technologie sur laquelle vous lisez, c'est-à-dire « Priorisez ce que votre client priorise ». Faire plus de travail là-dessus serait plus rapide, alors ne mettez pas les choses en travers de cela, mais ensuite des choses plus tactiques pour que les gens soient conscients, se tiennent au courant… et encore une fois, revenons directement à Google, mais web.dev se révèle être une ressource phénoménale pour les informations agnostiques sur les frameworks, les piles… Donc, si vous voulez en savoir plus sur les éléments vitaux, vous voulez en savoir plus sur les PWA, donc web.dev est vraiment génial.

Harry : Il y a en fait très peu de publications centrées sur la performance. L'e-mail de Calibre est, je pense que son e-mail de performance bimensuel est tout simplement phénoménal, c'est un très bon résumé. Gardez un œil sur la plate-forme Web en général, il y a donc le groupe de travail sur les performances, ils ont beaucoup de choses sur les propositions GitHub. Encore une fois, revenons à Google, mais personne ne connaît ce site Web et son phénoménal : chromestatus.com. Il vous indique exactement sur quoi Chrome travaille, quels sont les signaux des autres navigateurs, donc si vous voulez voir quel est le travail sur les indices de priorité, vous pouvez aller chercher des liens vers tous les traqueurs de bogues pertinents. Chrome Status vous montre des jalons pour chacun… "Ceci sort dans MAT8, cela a été publié en 67" ou peu importe, c'est une très bonne chose pour des informations assez techniques.

Harry : Mais je reviens sans cesse à cette chose, et je sais que je sonne probablement comme "le vieil homme crie à Cloud", mais restez sur les bases, presque chaque livre ou dollar, euro, que j'ai jamais gagné, a enseigné aux clients que "Vous savez que le navigateur le fait déjà, n'est-ce pas" ou "Vous savez que cela ne pourrait pas être plus rapide" et cela semble vraiment juste de ma part… Je n'ai jamais gagné un centime en vendant de la technologie supplémentaire. Chaque bit d'argent que je gagne consiste à enlever, soustraire. Si vous vous retrouvez à ajouter des éléments pour rendre votre site plus rapide, vous êtes dans la mauvaise direction.

Harry : Par exemple, je ne vais pas nommer… la grande entreprise de publicité/moteur de recherche/navigateur, je ne vais pas les nommer, et je ne vais pas nommer le framework JavaScript, mais je suis actuellement dans discussions avec un cadre JavaScript très, très grand et très populaire sur la suppression de quelque chose qui nuit activement, ou éventuellement la suppression de quelque chose qui nuirait aux performances d'un grand nombre de sites Web. Et ils étaient comme "Oh, nous allons faire une boucle dans..." quelqu'un de cette grande entreprise, parce qu'ils ont fait des recherches... et c'est comme "Nous avons besoin d'une option pour supprimer cette chose parce que vous pouvez voir ici, et ici, et ici, cela rend ce site plus lent. Et leur solution était d'en ajouter plus, comme "Oh mais si vous faites cela aussi, alors vous pouvez éviter cela" et c'est comme "Non, non, ajouter plus pour rendre un site plus rapide doit être la mauvaise solution. Vous pouvez sûrement voir que vous vous dirigez dans la mauvaise direction s'il faut plus de code pour se retrouver avec un site plus rapide.

Harry : Parce que c'était rapide au début, et tout ce que vous ajoutez est ce qui le rend plus lent. Et l'idée d'en ajouter plus pour le rendre plus rapide, bien que… cela puisse se manifester dans un site Web plus rapide, c'est le mauvais sens. C'est une course vers le bas. Désolé, je deviens vraiment énervé, vous pouvez dire que je n'ai pas fulminé depuis un moment. Donc c'est l'autre chose, si vous vous retrouvez à ajouter des fonctionnalités pour rendre un site plus rapide, vous vous dirigez probablement dans la mauvaise direction, il est bien plus efficace de rendre un site plus rapide en supprimant des choses qu'en les ajoutant.

Drew : Vous avez mis en place un cours vidéo intitulé "Tout ce que j'ai fait pour rendre CSS Wizardry Fast".

Harry : Ouais !

Drew : C'est un peu différent des cours vidéo en ligne traditionnels, n'est-ce pas ?

Harry : Ça l'est. Je vais être honnête, c'est en partie… Je ne veux pas dire de la paresse de ma part, mais je ne voulais pas concevoir un programme qui devait être très rigide et vous faire passer de zéro à héros parce que le temps nécessaire pour le faire est énorme et je ne savais pas si j'en aurais. Donc, ce que je voulais, c'était avoir du matériel prêt à l'emploi, il suffit de me projeter à l'écran pour qu'il ne commence pas par "Voici un navigateur et voici comment il fonctionne", vous devez donc au moins être conscient de les fondamentaux de la performance Web, mais ce sont des hacks, des conseils de pro et des exemples concrets.

Harry : Et parce que je n'avais pas besoin de suivre un cursus complet, j'ai pu faire baisser le prix. Ce n'est donc pas un grand parcours de 10 heures qui vous mènera de zéro à héros, c'est comme bon vous semble. Il s'agit essentiellement de regarder mon site qui est un excellent terrain de jeu pour les choses instables ou… c'est très peu risqué pour moi d'y expérimenter. Je viens donc de faire une série de vidéos. C'était une tonne de plaisir à enregistrer. Il suffit de démolir mon propre site et de parler de "Eh bien, voici comment cela fonctionne et voici comment vous pouvez l'utiliser".

Drew : Je pense que c'est vraiment génial de voir comment c'est divisé pour résoudre différents problèmes. Si je veux en savoir plus sur l'optimisation des images ou quoi que ce soit, je peux penser "Bon, qu'est-ce que mon pote Harry a à dire à ce sujet?", plonger dans la vidéo sur les images et c'est parti. C'est vraiment accessible de cette façon, vous n'avez pas à vous asseoir pendant des heures et des heures de choses, vous pouvez simplement aller à la partie que vous voulez et apprendre ce que vous devez apprendre, puis sortir.

Harry : Je pense que j'ai essayé de le garder plus… L'avantage de ne pas faire un programme rigide est que vous n'avez pas besoin de regarder une certaine vidéo en premier, il n'y a pas d'intro, c'est juste "Allez et regardez autour de vous et voyez ce que vous trouvez intéressant" ce qui signifie que quelqu'un souffrant de problèmes LTP se dit "Eh bien, je dois plonger dans ce dossier ici" ou s'il souffre de problèmes CSS, il peut aller plonger dans ce dossier. Évidemment, je n'ai pas de statistiques, mais j'imagine qu'il y a un taux d'abandon élevé sur les cours, simplement parce que vous devez parcourir trois heures d'introduction au cas où vous manqueriez quelque chose, et c'est comme "Oh, tu sais quoi, je ne peux pas continuez à le faire tous les jours » et les gens pourraient simplement abandonner beaucoup de cours. Donc ma pensée était juste de plonger, vous n'avez pas besoin d'avoir vu les trois heures précédentes, vous pouvez simplement aller trouver ce que vous voulez. Et les retours ont été vraiment, vraiment… En fait, ce que je vais faire, c'est que ça n'existe pas encore, mais je le ferai juste après l'appel, toute personne qui utilise le code de réduction SMASHING15, ils auront 15% de réduction de celui-ci.

Drew : Donc, c'est presque comme si vous aviez optimisé les performances du cours lui-même, parce que vous pouvez simplement aller directement à ce que vous voulez et vous n'avez pas à faire toute la négociation et-

Harry : Ouais, involontaire mais je m'en attribuerai le mérite.

Drew : Donc, j'ai tout appris sur les performances Web, qu'as-tu appris dernièrement, Harry ?

Harry : Des trucs techniques… pas vraiment. J'ai beaucoup de choses sur ma liste «à apprendre», donc QUIC, le genre de trucs H3, j'aimerais acquérir un peu plus de connaissances pratiques à ce sujet, mais j'ai écrit un livre électronique lors du premier verrouillage au Royaume-Uni, alors j'ai appris comment créer des livres électroniques, ce qui était très amusant parce qu'ils ne sont que du HTML et du CSS et que je connais mon chemin, donc c'était très amusant. J'ai appris le montage vidéo très rudimentaire pour le cours, et ce que j'ai aimé à ce sujet, ce n'est pas du travail conceptuel. Évidemment, pour apprendre un langage de programmation, il faut se débattre avec des concepts, alors qu'apprendre un livre électronique n'était que des flux de travail et… des choses avec lesquelles je n'avais jamais bricolé auparavant, donc c'était intéressant à apprendre mais cela ne nécessitait pas de changer de carrière. , donc c'était plutôt sympa.

Harry : Et puis, des trucs non techniques… Je fais beaucoup de vélo, je tombe beaucoup de vélo… et comme je n'ai pas du tout voyagé depuis mars dernier, presque un an maintenant, j'en fais beaucoup plus faire du vélo et se concentrer beaucoup plus sur… l'amélioration de cela. J'ai donc fait beaucoup de recherches autour des sorties de puissance et des puissances de seuil fonctionnel, je fais un programme d'entraînement en ce moment, donc constamment, constamment des jambes épuisées mais j'apprends beaucoup sur la physiologie autour du cyclisme. Je ne sais pas pourquoi parce que je n'ai pas l'intention de faire autre chose que de continuer à rouler. C'était vraiment fascinant. J'ai l'impression d'avoir eu beaucoup de chance pendant les confinements, au pluriel, mais j'ai réussi à rester active. Beaucoup de gens rateront des choses simples comme un trajet quotidien au bureau, une bonne occasion de se dégourdir les jambes. Au Royaume-Uni, comme vous le savez, le cyclisme a été très défendu, donc j'ai beaucoup bricolé pour en savoir plus sur le vélo d'un point de vue plus physiologique, ce qui signifie… je ne sais pas, juste être un nerd de autre chose pour changer.

Drew : N'y a-t-il peut-être pas tant de différence entre l'optimisation des performances sur le Web et l'optimisation des performances dans le cyclisme ? Ce ne sont que des gains marginaux, n'est-ce pas ?

Harry : Ouais, exactement. Et la quantité de graphiques que j'ai regardés sur le vélo... J'ai des données de puissance du vélo, je vais faire un tour et je reviens comme "Oh si j'avais cinq watts de plus ici mais que j'en ai économisé 10 watts là-bas, je pouvais faire ceci, cela et cela le plus rapidement jamais » et… j'ai été un énorme anorak à ce sujet. Mais oui, tu as raison. Savez-vous quoi, je pense que vous avez trouvé quelque chose de vraiment intéressant là-bas. Je pense que ce genre de chose est un bon sport/passe-temps pour quelqu'un qui est un peu obsédé, qui aime courir après les chiffres. Il y a des choses sur, je veux dire que vous le saurez mais, Strava, vous avez vos KOM. J'en ai empoché 19 l'année dernière, ce qui est pour moi une quantité phénoménale. Et c'est presque tout en étant obsédé par les données disponibles et en regardant "Ce gars que j'essaie de battre, il faisait 700 watts à ce stade, si je pouvais monter jusqu'à 1000 puis s'arrêter" et bla, bla, bla … c'est être obsessionnel. Ringard. Mais tu as raison, je suppose que c'est un genre de chose similaire, n'est-ce pas ? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

Harry : Ouais. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.