Dans cet épisode, nous parlons de Web Performance. À quoi ressemble le paysage des performances en 2021? J'ai parlé avec l'expert Harry Roberts pour le savoir.
Afficher les notes
Harry dirige un atelier Web Performance Masterclass avec Smashing en mai 2021. Au moment de la publication, de grosses réductions pour les débutants sont toujours disponibles
Mise à jour hebdomadaire
Transcription
Harry Roberts: Hé, je vous remercie beaucoup. Evidemment les 14 bras, sept jambes… posent 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 la 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 quitte le ballon des yeux et que je m'implique dans une sorte d'autre travail, puis je reviens à faire un peu de travail de performance, Je crains que les connaissances avec lesquelles je travaille ne deviennent vraiment obsolètes… Les performances Web évoluent-elles aussi rapidement que je le perçois?
Harry: C'est… Je ne dis même pas simplement ça pour soyez gentil avec vous, c'est une si bonne question parce que j'y ai réfléchi un peu ces derniers temps et je dirais qu'il y a deux moitiés. Une chose que j’essaierais de dire aux clients, c’est qu’en fait, cela ne va pas aussi vite. Principalement parce que, et c'est le son que j'utilise toujours, vous pouvez parier sur le navigateur. Les navigateurs ne sont pas vraiment autorisés à changer fondamentalement leur mode de fonctionnement, car, bien sûr, ils doivent conserver un héritage de deux décennies. Donc, généralement, si vous pariez sur le navigateur et que vous savez comment fonctionnent ces internes, 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 meilleure pratique en ce qui concerne les principes fondamentaux.
Harry: Là où cela devient plus intéressant, c'est… Ce que je vois de plus en plus, c'est que nous nous peignons 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 évolue, la manière dont il est construit et dont nous travaillons, nous nous posons de nouveaux défis. Ainsi, l'avènement de beaucoup plus de travail sur le client pose des problèmes de performances différents de ce que nous avions résolu 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é en cinq ans. Cela dépend donc en grande partie… Et je dirais qu'il y a définitivement deux côtés clairs… J'encourage mes clients à s'appuyer sur le navigateur, à s'appuyer sur les standards, car ils ne peuvent pas simplement être modifiés, les objectifs ne bougent pas vraiment . Mais, bien sûr, cela doit fusionner avec des pratiques de développement plus modernes et peut-être un peu plus intéressantes. Alors vous gardez votre… Eh bien, j'allais dire «Un pied dans les deux camps» mais avec mes sept pieds, je devrais… quatre et trois.
Drew: Vous avez mentionné que les fondamentaux ne sont pas t change et des choses comme TCP / IP ne changent pas. L'une des choses qui a changé en… 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 HTTP établi pour la communication entre les clients et les serveurs, et cela a changé et ensuite nous avons H2 qui est alors tout binaire et différent. Et cela a beaucoup changé… 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 changer à nouveau, 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 vraiment que H2 est beaucoup de fausses promesses et je pense qu'il a été précipité sur la ligne, 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 le perçoivent comme un nombre illimité de demandes de vol maintenant. Donc plutôt que six demandes expédiées et / ou six en vol à la fois, potentiellement illimitées, infinies. Cela pose des problèmes vraiment intéressants parce que… c'est assez difficile à décrire sans aides visuelles, mais vous avez toujours la même quantité de bande passante disponible, que vous exécutiez H1 ou H2, le protocole ne rend pas votre connexion plus rapide. Il est donc fort 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, en fait, vous n'allez pas plus vite parce que vous ne pouvez gérer, peut-être, qu'une fraction de cela à la fois.
Harry: Et ce à quoi vous devez également penser, c'est la façon dont les fichiers réagissent. Et ceci est un autre conseil de pro que je passe par les ateliers clients et cetera. Les gens regarderont une cascade H2 et verront qu'au lieu des six demandes de répartition traditionnelles, ils pourraient en voir 24. La distribution de 24 demandes 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 demandes, de sorte que votre côté gauche de votre cascade semble vraiment joli et raide, mais ils reviennent tous de manière assez décalée et séquentielle car vous devez limiter la quantité de bande passante. vous ne pouvez pas répondre à toutes les réponses en même temps.
Harry: Et bien, si vous deviez répondre à toutes les réponses en même temps, vous seriez des réponses entrelacées. Donc, la nuit, vous obtenez les 10 premiers% 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 lorsque vous regardez la réponse … Cela 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 existe des limites quant à son efficacité. Parce que vous verrez des gens trop partager 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 ensembles. Ils reviendront toujours assez séquentiellement. Elles n’arriveront pas toutes en même temps parce que vous n’avez pas vous-même ajouté 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 que vous ayez 100 millisecondes aller-retour et 250 millisecondes de téléchargement, soit deux fois 250 millisecondes. Si vous multipliez jusqu'à 24 demandes, vous avez toujours une latence constante, ce que nous avons décidé de 100 millisecondes, donc maintenant vous avez 2400 millisecondes de latence et 24 fois … au lieu de 250 millisecondes de téléchargement, disons son téléchargement de 25 millisecondes, cela prend en fait plus de temps car la latence reste constante et vous ne faites que multiplier cette latence par plus de requêtes. Je vais donc voir des clients qui auront lu que H2 est cette solution magique. Ils vont éclater… Oh! Ils ne pouvaient pas simplifier le processus de développement, nous n’avons pas besoin de regrouper ou de concaténer et cetera, et cetera. Et en fin de compte, cela finira par ralentir car vous avez réussi à répartir vos demandes, ce qui était la promesse, mais votre latence reste constante, vous avez donc en fait 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 dans ce processus de partitionnement dans cela, d'accord, pour obtenir tout le lot prend toujours le même temps, mais au moment où vous récupérez 100% du premier 24, vous pouvez commencer à travailler dessus et vous pouvez commencer à l'exécuter avant la fin du 24. [19659012] 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 exécuter dans l'ordre où ils arrivent. Vous pouvez donc raccourcir la durée totale en vous assurant que les choses arrivent en même temps. Si nous regardons 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 deviendra plus rapide. Et puis, vous bénéficiez des avantages induits de votre stratégie de mise en cache qui peut être plus précise. Donc, vraiment ennuyeux serait que vous mettiez à 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 CSS de votre site. Alors que maintenant, vous ne faites que mettre en cache datepicker.css. Nous avons donc des avantages secondaires comme celui-là, qui sont certainement, certainement très précieux.
Drew: Je suppose que dans le scénario où vous avez par magie récupéré toutes vos demandes en même temps, cela enliserait évidemment le problème. potentiellement client, n'est-ce pas?
Harry: Ouais, potentiellement. Et puis, ce qui se passerait réellement, c'est que le client devrait faire une charge de planification des ressources, de sorte que vous vous retrouveriez avec une cascade où toutes vos réponses reviennent en même temps, alors vous auriez un écart assez important entre les dernière réponse arrivée et sa capacité d'exécution. 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, que le serveur les renvoie tous dans le bon ordre afin que le navigateur puisse s'exécuter dans le bon ordre. Parce que, comme vous le dites, s'ils reviennent tous en même temps, vous venez de disposer d'un énorme JavaScript à exécuter en même temps, mais il doit encore être planifié. Ainsi, vous pourriez avoir un doute 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 requêtes 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 cherchez essentiellement pour une cascade de réponse qui semble que vous pourriez skier.
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 à voix haute, cela semble vraiment trivial, mais étant donné la façon dont H2 a été vendu, je trouve cela assez … pas difficile parce que cela rend mon client … stupide … mais c'est une 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 oui, je peux le voir maintenant". J'ai déjà dû enseigner cela aux ingénieurs de performance. Les gens qui font ce que je fais. J'ai dû enseigner aux ingénieurs de performance que cela ne nous dérangeait pas trop lorsque les demandes étaient faites, nous nous soucions vraiment de savoir quand les réponses deviennent utiles.
Drew: L'une des raisons pour lesquelles les choses semblent évoluer assez rapidement, surtout au cours des cinq dernières années, c'est que les performances sont un sujet important pour Google. Et lorsque Google met du poids derrière quelque chose comme ça, il gagne en popularité. Essentiellement, la performance est 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 je y pensait 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 l'accès plus d'un public. Alors oui, la performance est l'accessibilité appliquée, qui est donc l'expérience utilisateur. Et cette expérience utilisateur pourrait se résumer à "Quelqu'un pourrait-il même faire l'expérience de votre site". 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? ». Donc, je suis à 100% d'accord 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 vraiment 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, non? En utilisant un site où vous savez que la navigation n'est peut-être pas aussi 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 ensuite vous devez cliquer sur le bouton de retour et ensuite cette attente, et c'est juste … vous abandonnez.
Harry: Ouais, et c'est logique . Si vous vous rendez au supermarché et que vous voyez qu’il est absolument bourré 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’entrée et à la sortie. Alors que si c'est une belle expérience, vous avez "Oh, eh bien, pendant que je suis ici, je vais voir si … Oh, oui, ils ont ceci … Oh, je vais cuisiner ça demain soir" ou autre chose. Je pense encore, trois décennies dans le 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 le montrent.
Drew: Je pense que dans les tout premiers jours, je ' Je pensais à la fin des années 90, montrant mon âge ici, lorsque nous construisions des sites Web, nous pensions beaucoup à la performance, mais nous pensions à la performance d'un point de vue que les connexions que les gens utilisaient étaient si lentes. Nous parlons de commutateurs, 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 masqueraient avec une couleur unie pour donner cela … si vous pouvez l'imaginer comme en regardant l'image à travers un store vénitien. Et nous l'avons fait parce que cela a aidé à la compression. Parce que toutes les autres lignes, l'algorithme de compression pourrait –
Harry: Réduire en un seul pointeur.
Drew: Ouais. Vous avez donc considérablement réduit la taille de votre image tout en continuant 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, c'était principalement à quelle vitesse pourrions-nous faire avancer les choses. Pas pour l'expérience utilisateur, car 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 soient vraiment lentes, si cela a du sens.
Harry: Ouais, ouais.
Drew: Et puis, je Je pense que lorsque les vitesses comme les lignes ADSL sont devenues plus courantes, que nous avons arrêté de penser en ces termes et que nous 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'obtenir un avantage. Outre le côté expérience utilisateur, cela peut avoir de réels avantages commerciaux en termes de coûts et de capacité à faire des bénéfices. N'est-ce pas?
Harry: Oui, énormément. Je veux dire, je ne sais pas comment le dire. Je ne me tire pas une balle dans le pied ici, mais une chose que j'essaie de faire et que j'insiste 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 vitesse 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 avait d’énormes avantages à être rapide, de l’ordre de millions. Je travaille avec un client pendant que nous parlons. Nous avons pensé pour eux que s'ils pouvaient rendre une page donnée une seconde plus vite, ou plutôt que leur plus gros contenu 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 que. Mais oui, est-ce que l'aspect client… désolé, l'aspect client, 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, cela pourrait être qu'ils n'ont pas rebondi, ils ont en fait cliqué sur quelques articles de plus parce que nous l'avons rendu très simple et rapide. Et puis, les sites plus rapides sont moins chers à exécuter. Si vous avez trié votre stratégie de mise en cache, vous allez garder les gens à l'écart 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 fait est qu'il y a un coût pour y arriver. Je pense que Scott Jehl a probablement dit l'un des plus… Et je l'ai entendu d'abord de lui, donc je vais supposer qu'il l'a proposé, mais le dicton est «Il est facile de créer un site Web rapide mais c'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 poussées vers le bas de la liste des choses à faire est que vous pourriez être en mesure de dire à un client "Si je fais votre site une seconde plus vite, vous gagnerez 1,8 million de dollars supplémentaires par an" ou cela peut être «Si vous venez d'ajouter Apple Pay à votre paiement, vous gagnerez cinq millions supplémentaires.» Il ne s’agit donc pas uniquement de performances Web et ce n’est pas le facteur décisif, c’est une partie d’une stratégie beaucoup plus vaste, 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 juste là, vous avez absolument raison. C'est un avantage compétitif, cela vous rapportera plus d'argent.
Drew: À l'époque, encore une fois, je reviens à un temps passé, mais des gens comme Steve Souders ont été parmi les premiers à vraiment commencer écrire et parler de la performance web. Et des gens comme Steve disaient en gros: «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 relancé le test entre autrefois et maintenant, et l'écart s'était en fait élargi, donc c'est en fait plus coûteux sur le fil. Mais il y a un contre-courant à cela, c'est que si vous avez de très mauvaises performances backend, si vous sortez lentement de la porte, vous ne pouvez pas récupérer beaucoup de choses sur le front-end. J'ai un client pour le moment, leur temps de premier octet est de 1,5 seconde. Nous ne pouvons donc jamais rendre plus de 1,5 seconde, ce sera donc une limite. 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 backend, il y a une limite à la vitesse à laquelle vos efforts de performance frontaux pourraient vous atteindre. Mais absolument.
Harry: Cela change cependant parce que… Eh bien, non, ça ne change pas je suppose, ça empire. Nous poussons davantage le client. Auparavant, c'était un cas de "Votre serveur est aussi rapide qu'il est, mais après cela, nous avons un tas de points d'interrogation." parce que j'entends cela tout le temps «Tous nos utilisateurs fonctionnent en WiFi. Ils ont tous des ordinateurs de bureau car ils travaillent tous depuis notre bureau. » Eh bien, non, maintenant ils travaillent tous à domicile. Vous n’avez pas le droit de choisir. Donc, c’est là que tous les points d’interrogation interviennent, où se produisent les ralentissements, où vous ne pouvez pas vraiment le contrôler. Après cela, le fait que maintenant nous avons tendance à mettre plus sur le client. Je veux dire par là, des temps d'exécution entiers sur le client. De toute façon, vous avez déplacé toute la logique de votre application 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 ne fonctionne pas sur Netflix sur la même machine sur laquelle il essaie de consulter 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é que vous devriez essayer de répondre à toutes sortes de navigateurs, toutes sortes de vitesses de connexion, toutes sortes des tailles d'écran, parce que vous ne savez pas à quoi va s'attendre l'utilisateur. 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, ils exécutent ce navigateur, c'est la dernière version, ils sont câblés au LAN" mais alors les choses arrivent. L'un des grands avantages des applications Web est que nous pouvons faire des choses comme répartir soudainement notre main-d'œuvre chez eux et qu'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 à la maison qui pourrait avoir IE11 dessus ou autre, si la qualité du travail est là qui signifie réellement que le Web accomplit son potentiel en étant un support vraiment accessible.
Drew: Comme vous le dites, il y a cette tendance à déplacer 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 était rendu à presque 100% par le serveur. Il y a très peu de JavaScript et il est ultra-rapide. 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 ça se sente vite. C'est votre site de développement.
Drew: Ensuite, mon travail de jour, nous développons notre application d'une seule page et déplaçons des éléments hors 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 d'être sur le serveur? S'agit-il simplement de le mesurer et de le prendre au cas par cas?
Harry: Je pense que vous devez être très, très, très conscient de votre contexte et… vraiment je pense qu'une erreur est … Le narcissisme où les gens pensent «Oh, mon blog mérite d'être rendu dans le navigateur de quelqu'un. Mon blog avec un taux de rebond de 89% a besoin de son propre environnement 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 runtime 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 faire du mal, 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 de lecture et d’écriture intensive, vous devez donc saisir des données, manipuler des données, etc. Fondamentalement, mon site n’est pas une application Web, c’est un site Web, en lecture seule, que je mettrais fermement dans le camp des sites 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. Vous avez donc 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, non. Non, non. Les gens ont un bloqueur de publicités activé, 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 se plaindre à ce sujet sur Facebook. Ne construisez pas quelque chose comme ça en tant qu'application rendue par le client, ce n'est pas approprié.
Harry: Donc je pense qu'il y a certainement un moment où passer davantage au client aiderait, et c'est à ce moment-là que vous ' J'ai moins de sensibilité au désabonnement. Donc tout type de com, par exemple, je fais un audit pour 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 id = "app" vide. E-Com c'est… vous êtes très sensible à tous les problèmes. Votre flux de paiement est même subtilement faux, je pars ailleurs. C’est trop lent, je pars ailleurs. Vous n’avez pas le contexte dans lequel quelqu'un est prêt à se mettre au lit 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… 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 «Ne faites pas ça», car je ne peux pas simplement dire «Combien de temps pensez-vous que votre utilisateur sera là». Et vous pouvez calculer une approximation de… si votre taux de rebond de 89% n’est pas optimisé pour une deuxième page vue. Réduisez d'abord ce taux de rebond. Je pense qu'il y a définitivement 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 dans le client des éléments qui ne devraient pas être là. CNN, par exemple, vous ne pouvez pas lire un seul titre sur le site Web de CNN tant que l'application JavaScript n'est pas complètement démarrée. Le seul élément rendu par le serveur est l’en-tête et le pied de page, ce qui est 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 nous en arrivons là. Ce ne sera jamais la meilleure option. Vous livrez une page qui est effectivement inutile qui doit alors dire "Cool, je vais aller 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. Cela me dérange 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 très dur mais… Il s'agit essentiellement d'une mise en œuvre 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 les plus intelligents de Facebook, et c'est vraiment, vraiment cruel et cela semble horrible à dire, mais vous ne pouvez obtenir … 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 une application cliente rapidement, alors que pour rendre une application 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 verres teintés de rose, de naïveté, de marketing… J'ai l'air si sombre, nous devons passer à autre chose avant de commencer à vraiment perdre des gens ici.
Drew: Pensez-vous que nous avons la tendance, en tant qu'industrie, se concentrer davantage sur l'expérience des développeurs que sur l'expérience utilisateur parfois?
Harry: Pas dans son ensemble, mais je pense que ce problème surgit à un endroit auquel vous vous attendez. Si vous regardez la disparité … je ne sais pas si vous avez vu cela mais je vais présumer que vous avez, vous semblez très bien 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'état de l'enquête JavaScript, si vous suivez l'état de l'enquête JavaScript, cela dirait «Oh oui, 75% des développeurs utilisent React» alors que moins de 5% des sites utilisent React. Donc, j'ai l'impression qu'en masse, je ne pense pas que ce soit un problème, mais je pense que dans les domaines auxquels vous vous attendez, une forte fidélité à un framework par exemple, l'expérience des développeurs est… évangélisée probablement avant l'utilisateur. Je ne pense pas que l'expérience des développeurs doive être négligée, je veux dire, tout a un coût de maintenance. Ta voiture. Il y a eu une décision lors de la conception: «Eh bien, si nous cachons cette clé, cette fonctionnalité, à un mécanicien, cela prendra beaucoup plus de temps à ce mécanicien pour le réparer, donc nous ne faisons pas des choses comme ça». Il faut donc un équilibre entre ergonomie et convivialité, je pense que c'est important. Je pense que me concentrer principalement sur l'expérience des développeurs est tout simplement déroutant pour moi. Don’t optimize for you, optimize for your customer, your customer pays you it’s not the other way around.
Drew: So the online echo chamber isn’t exactly representative of reality when you see everybody saying “Oh you should be using this, you should be doing that” then that’s actually only a very small percentage of people.
Harry: Correct, and that’s a good thing, that’s reassuring. The echo chamber… it’s not healthy to have that kind of monoculture perhaps, if you want to call it that. But also, I feel like… and I’ve seen it in a lot of my own work, a lot of developers… As a consultant, I work with a lot of different companies. A lot of people are doing amazing work in WordPress. And WordPress powers 24% of the web. And I feel like it could be quite easy for a developer like that working in something like WordPress or PHP on the backend, custom code, whatever it is, to feel a bit like “Oh, I guess everyone’s using React and we aren’t” but actually, no. Everyone’s talking about React but you’re still going with the flow, you’re still with the majority. It’s quite reassuring to find the silent majority.
Drew: The trend towards static site generators and then hosting sites entirely on a CDN, sort of JAMstack approach, I guess when we’re talking about those sorts of publishing type sites, rather than software type sites, I guess that’s a really healthy trend, would you think?
Harry: I love that, absolutely. You remember when we used to call SSG “flap file”, right?
Drew: Yeah.
Harry: So, I built CSS Wizardry on Jekyll back when Jekyll was called a flap file website. 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: Yeah.
Harry: … diminishing returns, that’s exactly it. Yeah, exactly.
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? This is so good. 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: He commanded respect but he was one of the lads, we all really liked him. But he was massive in every dimension. Well over six foot tall, but just a big lad. Big, big, big, big man. And he said to us “If you were to design a doorway, would you design it for the average person?” And 15 year old brains are going “Well yeah, if everyone’s roughly 5’9 then yeah” He was like “Well, immediately, Harry can’t use that door.” You don’t design for the average person, you design for the extremities because you want it to be useful to the most people. If you designed a chair for the average person, Mr. Brocklesby wasn’t going to fit in it. So he taught me from a really, really age, design to your extremities.
Harry: And where that becomes really interesting in web perf is… If you imagine a ladder, and you pick up the ladder by the bot… Okay I’ve just realized my metaphor might… I’ll stick with it and you can laugh at me afterwards. Imagine a ladder and you lift the ladder up by the bottom rungs. And that’s your worst experiences. You pick the bottom rung in the ladder to lift it up. The whole ladder comes with it, like a rising tide floats all boats. The reason that metaphor doesn’t work is if you pick a ladder up by the top rung, it all lifts as well, it’s a ladder. And the metaphor doesn’t even work if I turn it into a rope ladder, because a rope ladder then, you lift the bottom rung and nothing happens but… my point is, if you can improve experience for your 90th percentile, it’s got to get that up for your 10th percentile, right?
Harry: And this is why I tell clients, they’ll say to me things like “Oh well most of our users are on 4G on iPhones” so like all right, okay, and we start testing 3G on Android, like “No, no, most of our users are iPhones” okay… that means your average user’s going to have a better experience but anyone who isn’t already in the 50th percentile just gets left further behind. So set the bar pretty high for yourself by setting expectations pretty low.
Harry: Sorry, I’ve got a really bad habit of giving really long answers to short questions. But it was a fantastic question and, to try and wrap up, 100% definitely I agree with you that you want to look at that long-tail, you want to look at that… your 80th percentile because if you take all the experiences on the site and look at the median, and you improve the median, that means you’ve made it even better for people who were already quite satisfied. 50% of people being effectively ignored is not the right approach. And yeah, it always comes back to Mr Brocklesby telling me “Don’t design for the average person because then Harry can’t use the door”. Oh, for anyone listening, I’m 193 centimeters, so I’m quite lanky, that’s what that is.
Drew: And all those arms and legs.
Harry: Yeah. Here’s another good one as well. My girlfriend recently discovered the accessibility settings in iOS… so everyone has their phone on silent, right? Nobody actually has a phone that actually rings, everyone’s got it on silent. She found that “Oh you know, you can set it so that when you get a message, the flash flashes. And if you tap the back of the phone twice, it’ll do a screenshot.” And these are accessibility settings, these are designed for that 95th percentile. Yet she’s like “Oh, this is really useful”.
Harry: Same with OXO Good Grips. OXO Good Grips, the kitchen utensils. I’ve got a load of them in the kitchen. They’re designed because the founder’s wife had arthritis and he wanted to make more comfortable utensils. He designed for the 99th percentile, most people don’t have arthritis. But by designing for the 99th percentile, inadvertently, everyone else is like “Oh my God, why can’t all potato peelers be this comfortable?” And I feel like it’s really, really… I like a feel-good or anecdote that I like to wheel out in these sort of scenarios. But yeah, if you optimize for them… Well, a rising tide floats all boats and that therefore optimizes the tail-end of people and you’re going to capture a lot of even happier customers above that.
Drew: Do you have the OXO Good Grips manual hand whisk?
Harry: I don’t. I don’t, is it good?
Drew: Look into it. It’s so good.
Harry: I do have the OXO Good Grips mandolin slicer which took the end of my finger off last week.
Drew: Yeah, I won’t get near one of those.
Harry: Yeah, it’s my own stupid fault.
Drew: Another example from my own experience with catering for that long-tail is that, in the project I’m working on at the moment, that long-tail is right at the end, you’ve got people with the slowest performance, but if it turns out if you look at who those customers are, they’re the most valuable customers to the business-
Harry: Okay.
Drew: … because they are the biggest organizations with the most amount of data.
Harry: Right.
Drew: And so they’re hitting bottlenecks because they have so much data to display on a page and those pages need to be refactored a little bit to help that use case. So they’re having the slowest experience and they’re, when it comes down to it, paying the most money and making so much more of a difference than all of the people having a really fast experience because they’re free users with a tiny amount of data and it all works nice and it is quick.
Harry: That’s a fascinating dimension, isn’t it? In fact, I had a similar… I had nowhere near the business impact as what you’ve just described, but I worked with a client a couple of years ago, and their CEO got in touch because their site was slow. Like, slow, slow, slow. Really nice guy as well, he’s just a really nice down to earth guy, but he’s mentored, like proper rich. And he’s got the latest iPhone, he can afford that. He’s a multimillionaire, he spends a lot of his time flying between Australia, where he is from, and Estonia, where he is now based.
Harry: And he’s flying first class, course he is. But it means most of his time on his nice, shiny iPhone 12 Pro Max whatever, whatever, is over airplane WiFi, which is terrible. And it was this really amazing juxtaposition where he owns the site and he uses it a lot, it’s a site that he uses. And he was pushing it… I mean easily their richest customer was their CEO. And he’s in this weirdly privileged position where he’s on a worse connection than Joe Public because he’s somewhere above Singapore on a Quantas flight getting champagne poured down his neck, and he’s struggling. And that was a really fascinating insight that… Oh yeah, because you’ve got your 95th percentile can basically can go in either direction.
Drew: Yeah, it’s when you start optimizing for using a site with a glass of champagne in one hand that you think “Maybe we’re starting to lose the way a bit.”
Harry: Yeah, exactly.
Drew: We talked a little bit about measurement of performance, and in my own experience with performance work it’s really essential to measure everyhtin.g A so you can identify where problems are but B so that when you actually start tackling something you can tell if you’re making a different and how much of a difference you’re making. How should we be going about measuring the performance of our sites? What tools can we use and where should we start?
Harry: Oh man, another great question. So there’s a range of answers depending on how much time, resources, inclination there is towards fixing site speed. So what I will try and do with client is… Certain off the shelf metrics are really good. Load time, do not care about that anymore. It’s very, very, very… I mean, it’s a good proxy if your load time’s 120 seconds I’m going to guess you don’t have a very fast website, but it’s too obscure and it’s not really customer facing. I actually think vitals are a really good step in the right direction because they do measure user experience but they’re based on technical input. Largest Contentful Paint is a really nice thing to visual but the technical stuff there is unblock your critical path, make sure hero images arrive quickly and make sure your web font strategy is decent. There’s a technical undercurrent to these metrics. Those are really good off the shelf.
Harry: However, if clients have got the time, it’s usually time, because you want to capture the data but you need time to actually capture the data. So what I try and do with clients is let’s go “Look, we can’t work together for the next three months because I’m fully booked. So, what we can do is really quickly set you up with a free trial of Speedcurve, set up some custom metrics” so that means that for a publisher client, a newspaper, I’d be measuring “How quickly was the headline of the article rendered? How quickly was the lead image for the article rendered?” For an E-Commerce client I want to measure, because obviously you’re measuring things like start render passively. As soon as you start using any performance monitoring software, you’re capturing your actual performance metrics for free. So your First Contentful Paint, Largest Contentful, etc. What I really want to capture is things that matter to them as a business.
Harry: So, working with an E-Com client at the moment where we are able to correlate… The faster your start render, what is the probability to an adding to cart. If you can show them a product sooner, they’re more likely to buy it. And this is a lot of effort to set up, this is kind of the stretch goal for clients who are really ambition, but anything that you really want to measure, because like I say, you don’t really want to measure what your Largest Contentful Paint is, you want to measure your revenue and was that influenced by Large Contentful Paint? So the stretch goal, ultimate thing, would be anything you would see as a KPI for that business. It could be, on newspapers, how far down the article did someone scroll? And does that correlate in any way to first input delay? Did people read more articles if CLS was lower? But then before we start doing custom, custom metrics, I honestly think web vitals is a really good place to start and it’s also been quite well normalized. It becomes a… I don’t know what the word is. Lowest common denominator I guess, where everyone in the industry now can discuss performance on this level playing field.
Harry: One problem I’ve got, and I actually need to set up a meeting with the vitals team, is I also really think Lighthouse is great, but CLS is 33% of web vitals. You’ve got LCP, FID, CLS. CLS is 33% of your vitals. Vitals is what normally goes in front of your marketing team, your analytics department, because it pops up in search console, it’s mentioned in context of search results pages, whereas vitals is concerned, you’ve got heavy weighting, 33%, a third of vitals is CLS, it’s only 5% of our Lighthouse score. So what you’re going to get is developers who build around Lighthouse, because it can be integrated into tooling, it’s a lab metric. Vitals is field data, it’s rum.
Harry: So you’ve got this massive disconnect where you’ve got your marketing team saying “CLS is really bad” and developers are thinking “Well it’s 5% of the Lighthouse score that DevTools is giving me, it’s 5% of the score that Lighthouse CLI gives us in CircleCI” or whatever you’re using, yet for the marketing team its 33% of what they care about. So the problem there is a bit of a disconnect because I do think Lighthouse is very valuable, but I don’t know how they reconcile that fairly massive difference where in vitals, CLS is 33% of your score… well, not score because you don’t really have one, and Lighthouse is only 5%, and it’s things like that that still need ironing out before we can make this discussion seamless.
Harry: But, again, long answer to a short question. Vitals is really good. LCP is a good user experience metric which can be boiled down to technical solutions, same with CLS. So I think that’s a really good jump off point. Beyond that, it’s custom metrics. What I try and get my clients to is a point where they don’t really care how fast their site is, they just care that they make more money from yesterday, and if it did is that because it was running fast? If it made less is that because it was running slower? I don’t want them to chase a mystical two second LCP, I want them to chase the optimal LCP. And if that actually turns out to be slower than what you think, then whatever, that’s fine.
Drew: So, for the web developer who’s just interested in… they’ve not got budget to spend on tools like Speedcurve and things, they can obviously run tools like Lighthouse just within their browser, to get some good measurement… Are things like Google Analytics useful for that level?
Harry: They are and they can be made more useful. Analytics, for many years now, has captured rudimentary performance information. And that is going to be DNS time, TCP and TLS, time to first byte, page download time, which is a proxy… well, whatever, just page download time and load time. So fairly clunky metrics. But it’s a good jump off point and normally every project I start with a client, if they don’t have New Relic or Speedcurve or whatever, I’ll just say “Well let me have a look at your analytics” because I can at least proxy the situation from there. And it’s never going to be anywhere near as good as something like Speedcurve or New Relic or Dynatrace or whatever. You can send custom metrics really, really, really easily off to analytics. If anyone listening wants to be able to send… my site for example. I’ve got metrics like “How quickly can you read the heading of one of my articles? At what point was the About page image rendered? At what point was the call to action that implores you to hire me? How soon is that rendered to screen?” Really trivial to capture this data and almost as trivial to send it to analytics. So if anyone wants to view source on my site, scroll down to the closing body tag and find the analytics snippet, you will see just how easy it is for me to capture custom data and send that off to analytics. And, in the analytics UI, you don’t need to do anything. Normally you’d have to set up custom reports and mine the data and make it presentable. These are a first class citizen in Google Analytics. So the moment you start capturing custom analytics, there’s a whole section of the dashboard dedicated to it. There’s no setup, no heavy lifting in GA itself, so it’s really trivial and, if clients are on a real budget or maybe I want to show them the power of custom monitoring, I don’t want to say “Oh yeah, I promise it’ll be really good, can I just have 24 grand for Speedcurve?” I can start by just saying “Look, this is rudimentary. Let’s see the possibilities here, now we can maybe convince you to upgrade to something like Speedcurve.”
Drew: I’ve often found that my gut instinct on how fast something should be, or what impact a change should have, can be wrong. I’ll make a change and think I’m making things faster and then I measure it and actually I’ve made things slower. Is that just me being rubbish at web perf?
Harry: Not at all. I’ve got a really pertinent example of this. Preload… a real quick intro for anyone who’s not heard of preload, loading certain assets on the web is inherently very slow and the two primary candidates here are background images in CSS and web fonts, because before you can download a background image, you have to download the HTML, which then downloads the CSS, and then the CSS says “Oh, this div on the homepage needs this background image.” So it’s inherently very slow because you’ve got that entire chunk of CSS time in between. With preload, you can put one line in HTML in the head tag that says “Hey, you don’t know it yet but, trust me, you’ll need this image really, really, really soon.” So you can put a preload in the HTML which preemptively fires off this download. By the time the CSS needs the background image, it’s like “Oh cool, we’ve already got it, that’s fast.” And this is toutered as this web perf Messiah… Here’s the thing, and I promise you, I tweeted this last week and I’ve been proved right twice since. People hear about preload, and the promise it gives, and also it’s very heavily pushed by Lighthouse, in theory, it makes your site faster. People get so married to the idea of preload that even when I can prove it isn’t working, they will not remove it again. Because “No, but Lighthouse said.” Now this is one of those things where the theory is sound. If you have to wait for your web font, versus downloading it earlier, you’re going to see stuff faster. The problem is, when you think of how the web actually works, any page you first hit, any brand new domain you hit, you’ve got a finite amount of bandwidth and the browser’s very smart spending that bandwidth correctly. It will look through your HTML really quickly and make a shopping list. Most important thing is CSS, then it’s this jQuery, then it’s this… and then next few things are these, these, and these less priority. As soon as you start loading your HTML with preloads, you’re telling the browser “No, no, no, this isn’t your shopping list anymore, buddy, this is mine. You need to go and get these.” That finite amount of bandwidth is still finite but it’s not spent across more assets, so everything gets marginally slower. And I’ve had to boo this twice in the past week, and still people are like “Yeah but no it’s because it’s downloading sooner.” No, it’s being requested sooner, but it’s stealing bandwidth from your CSS. You can literally see your web fonts are stealing bandwidth from your CSS. So it’s one of those things where you have to, have to, have to follow the numbers. I’ve done it before on a large scale client. If you’re listening to this, you’ve heard of this client, and I was quite insistent that “No, no, your head tags are in the wrong order because this is how it should be and you need to have them in this order because theoretically it clues in that…” Even in what I was to the client I knew that I was setting myself up for a fool. Because of how browsers work, it has to be faster. So I’m making the ploy, this change… to many millions of people, and it got slower. It got slower. And me sitting there, indignantly insisting “No but, browsers work like this” is useless because it’s not working. And we reverted it and I was like “Sorry! Still going to invoice you for that!” So it’s not you at all.
Drew: Follow these numbers.
Harry: Yeah, exactly. “I actually have to charge you more, because I spent time reverting it, took me longer.” But yeah, you’re absolutely right, it’s not you, it’s one of those things where… I have done it a bunch of times on a much smaller scale, where I’ll be like “Well this theoretically must work” and it doesn’t. You’ve just got to follow what happens in the real world. Which is why that monitoring is really important.
Drew: As the landscape changes and technology develops, Google rolls out new technologies that help us make things faster, is there a good way that we can keep up with the changes? Is there any resources that we should be looking at to keep our skills up to date when it comes to web perf?
Harry: To quickly address the whole “Google making”… I know it’s slightly tongue in cheek but I’m going to focus on this. I guess right towards the beginning, bet on the browser. Things like AMP, for example, they’re at best a after thought catch of a solution. There’s no replacement for building a fast site, and the moment you start using things like AMP, you have to hold on to those non-standard standards, the mercy of the AMP team changing their mind. I had a client spend a fortune licensing a font from an AMP allow-listed font provider, then at some point, AMP decided “Oh actually no, that font provided, we’re going to block list them now” So I had a client who’s invested heavily in AMP and this font provider and had to choose “Well, do we undo all the AMP work or do we just waste this very big number a year on the web font” blah, blah, blah. So I’d be very wary of any one… I’m a Google Developer expert but I don’t know of any gagging-order… I can be critical, and I would say… avoid things that are hailed as a one-size-fits-all solution, things like AMP.
Harry: And to dump on someone else for a second, Cloudflare has a thing called Rocket Loader, which is AMP-esque in its endeavor. It’s designed like “Oh just turn this thing on your CDN, it’ll make your site faster.” And actually it’s just a replacement for building your site properly in the first place. So… to address that aspect of it, try and remain as independent as possible, know how browsers work, which immediately means that Chrome monoculture, you’re back in Google’s lap, but know how browsers work, stick to some fundamental ideologies. When you’re building a site, look a the page. Whether that’s in Figma, or Sketch, or wherever it is, look at the design and say “Well, that is what a user wants to see first, so I’ll put nothing in the way of that. I won’t lazy load this main image because that’s daft, why would I do that?” So just think about “What would you want the user to be first?” On an E-Com site, it’s going to be that product image, probably nav at the same time, but reviews of the product, Q and A of the product, lazy load that. Tuck that behind JavaScript.
Harry: Certain fundamental ways of working that will serve you right no matter what technology you’re reading up on, which is “Prioritize what your customer prioritizes”. Doing more work on that’d be faster, so don’t put things in the way of that, but then more tactical things for people to be aware of, keep abreast of… and again, straight back to Google, but web.dev is proving to be a phenomenal resource for framework agnostic, stack agnostic insights… So if you want to learn about vitals, you want to learn about PWAs, so web.dev’s really great.
Harry: There’s actually very few performance-centric publications. Calibre’s email is, I think its fortnightly perf email is just phenomenal, it’s a really good digest. Keep an eye on the web platform in general, so there’s the Performance Working Group, they’ve got a load of stuff on GitHub proposals. Again, back to Google, but no one knows about this website and its phenomenal: chromestatus.com. It tells you exactly what Chrome’s working on, what the signals are from other browsers, so if you want to see what the work is on priority hints, you can go and get links to all the relevant bug trackers. Chrome Status shows you milestones for each… “This is coming out in MAT8, this was released in ’67” or whatever, that’s a really good thing for quite technical insights.
Harry: But I keep coming back to this thing, and I know I probably sound like “Old man shouts at Cloud” but stick to the basics, nearly every single pound or dollar, euro, I’ve ever earned, has been teaching clients that “You know the browser does this already, right” or “You know that this couldn’t possible be faster” and that sounds really righteous of me… I’ve never made a cent off of selling extra technology. Every bit of money I make is about removing, subtracting. If you find yourself adding things to make your site faster, you’re in the wrong direction.
Harry: Case in point, I’m not going to name… the big advertising/search engine/browser company at all, not going to name them, and I’m not going to name the JavaScript framework, but I’m currently in discussions with a very, very big, very popular JavaScript framework about removing something that’s actively harming, or optionally removing something that would harm the performance of a massive number of websites. And they were like “Oh, we’re going to loop in…” someone from this big company, because they did some research… and it’s like “We need an option to remove this thing because you can see here, and here, and here it’s making this site slower.” And their solution was to add more, like “Oh but if you do this as well, then you can sidestep that” and it’s like “No, no, adding more to make a site faster must be the wrong solution. Surely you can see that you’re heading in the wrong direction if it takes more code to end up with a faster site.”
Harry: Because it was fast to start with, and everything you add is what makes it slower. And the idea of adding more to make it faster, although… it might manifest itself in a faster website, it’s the wrong way about it. It’s a race to the bottom. Sorry, I’m getting really het up, you can tell I’ve not ranted for a while. So that’s the other thing, if you find yourself adding features to make a site faster, you’re probably heading in the wrong direction, it’s far more effective to make a faster by removing things than it is to add them.
Drew: You’ve put together a video course called “Everything I Have Done to Make CSS Wizardry Fast”.
Harry: Yeah!
Drew: It’s a bit different from traditional online video courses, isn’t it?
Harry: It is. I’ll be honest, it’s partly… I don’t want say laziness on my part, but I didn’t want to design a curriculum which had to be very rigid and take you from zero to hero because the time involved in doing that is enormous and time I didn’t know if I would have. So what I wanted to was have ready-to-go material, just screen cast myself talking through it so it doesn’t start off with “Here is a browser and here’s how it works” so you do need to be at least aware of web perf fundamentals, but it’s hacks and pro-tips and real life examples.
Harry: And because I didn’t need to do a full curriculum, I was able to slam the price way down. So it’s not a big 10 hour course that will take you from zero to hero, it’s nip in and out as you see fit. It’s basically just looking at my site which is an excellent playground for things that are unstable or… it’s very low risk for me to experiment there. So I’ve just done video series. It was a ton of fun to record. Just tearing down my own site and talking about “Well this is how this works and here’s how you could use it”.
Drew: I think it’s really great how it’s split up into solving different problems. If I want to find out more about optimizing images or whatever, I can think “Right, what does my mate Harry have to say about this?”, dip in to the video about images and off I go. It’s really accessible in that way, you don’t have to sit through hours and hours of stuff, you can just go to the bit you want and learn what you need to learn and then get out.
Harry: I think I tried to keep it more… The benefit of not doing a rigid curriculum is you don’t need to watch a certain video first, there’s no intro, it’s just “Go and look around and see what you find interesting” which meant that someone suffering with LTP issues they’re like “Oh well I’ve got to dive into this folder here” or if they’re suffering with CSS problems they can go dive into that folder. Obviously I have no stats, but I imagine there’s a high abandonment rate on courses, purely because you have to trudge through three hours of intro in case you do miss something, and it’s like “Oh, do you know what, I can’t keep doing this every day” and people might just abandon a lot of courses. So my thinking was just dive in, you don’t need to have seen the preceding three hours, you can just go and find whatever you want. And feedback’s been really, really… In fact, what I’ll do is, it doesn’t exist yet, but I’ll do it straight after the call, anybody who uses the discount code SMASHING15, they’ll get 15% off of it.
Drew: So it’s almost like you’ve performance optimized the course itself, because you can just go straight to the bit you want and you don’t have to do all the negotiation and-
Harry: Yeah, unintentional but I’ll take credit for that.
Drew: So, I’ve been learning all about web performance, what have you been learning about lately, Harry?
Harry: Technical stuff… not really. I’ve got a lot on my “to learn” list, so QUIC, H3 sort of stuff I would like to get a bit more working knowledge of that, but I wrote an E-Book during first lockdown in the UK so I learned how to make E-Books which was a ton of fun because they’re just HTML and CSS and I know my way around that so that was a ton of fun. I learnt very rudimentary video editing for the course, and what I liked about those is none of that’s conceptual work. Obviously, learning a programming language, you’ve got to wrestle concepts, whereas learning an E-Book was just workflows and… stuff I’ve never tinkered with before so it was interesting to learn but it didn’t require a change of career, so that was quite nice.
Harry: And then, non technical stuff… I ride a lot of bikes, I fall off a lot of bikes… and because I’ve not traveled at all since last March, nearly a year now, I’ve been doing a lot more cycling and focusing a lot more on… improving that. So I’ve been doing a load of research around power outputs and functional threshold powers, I’m doing a training program at the moment, so constantly, constantly exhausted legs but I’m learning a lot about physiology around cycling. I don’t know why because I’ve got no plans of doing anything with it other than keep riding. It’s been really fascinating. I feel like I’ve been very fortunate during lockdowns, plural, but I’ve managed to stay active. A lot of people will miss out on simple things like a daily commute to the office, a good chance to stretch legs. In the UK, as you’ll know, cycling has been very much championed, so I’ve been tinkering a lot more with learning more about riding bikes from a more physiological aspect which means… don’t know, just being a nerd about something else for a change.
Drew: Is there perhaps not all that much difference between performance optimization on the web and performance optimization in cycling, it’s all marginal gains, right?
Harry: Yeah, exactly. And the amount of graphs I’ve been looking at on the bike… I’ve got power data from the bike, I’ll go out on a ride and come back like “Oh if I had five more watts here but then saved 10 watts there, I could do this, this, and this the fastest ever” and… been a massive anorak about it. But yeah, you’re right. Do you know what, I think you’ve hit upon something really interest there. I think that kind of thing is a good sport/pastime for somebody who is a bit obsessive, who does like chasing numbers. There are things on, I mean you’ll know this but, Strava, you’ve got your KOMs. I bagged 19 of them last year which is, for me, a phenomenal amount. And it’s nearly all from obsessing over available data and looking at “This guy that I’m trying to beat, he was doing 700 watts at this point, if I could get up to 1000 and then tail off” and blah, blah, blah… it’s being obsessive. Nerdy. But you’re right, I guess it’s a similar kind of thing, isn’t it? 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: Yeah. 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.
Source link