Le défi de la performance frontale : gagnant et résultats

Il y a quelques semaines, nous avons demandé à nos lecteurs et à la communauté d'utiliser tout ce qu'ils pouvaient pour que leurs sites Web et leurs projets fonctionnent à une vitesse fulgurante. Aujourd'hui, nous sommes ravis de montrer les résultats de ce défi et d'annoncer le gagnant qui recevra en effet des prix sensationnels !

Quels prix, demandez-vous? Le gagnant remporte un vol aller-retour pour Londres, un hébergement complet dans un hôtel chic, un billet pour SmashingConf Londres 2018 et, enfin et surtout, un atelier Smashing de son choix.

Défi? Quel défi ?

Eh bien, la tâche n'était pas aussi simple qu'il y paraissait. Les candidats devaient améliorer les performances d'un site Web tout en gardant l'aspect visuel final identique avant et après. Le chargement des polices était autorisé à différer et les refusions étaient acceptables tant qu'elles étaient réduites au minimum.

Lors du choix de l'heureux gagnant, nous avons examiné les résultats présentés par Lighthouse et WebPageTest, ainsi que la complexité des sites Web sur lesquels nos participants avaient travaillé, bien sûr. La première peinture significative et le temps d'interactivité étaient les paramètres les plus critiques.

Mais assez de faits concrets pour le moment. Nous savons que vous êtes déjà curieux et nous ne voulons plus vous tenir en haleine. Alors le voici, le projet gagnant.

Et le gagnant est…

Léonard Losoviz

Les techniques d'optimisation présentées dans la soumission de Leonardo sont toutes du bricolage, conçues et mises en œuvre à partir de zéro. Il a ajouté toutes les optimisations à PoP, un framework open-source pour créer des sites Web, et a utilisé Agenda Urbana pour tester les améliorations de performances sur un projet réel.

Nous avons estimé que cette soumission s'inscrivait vraiment dans l'esprit du défi non seulement en améliorant les performances d'un seul site Web, mais en tentant d'apporter des améliorations à un cadre utilisé sur un certain nombre de sites Web. Le fait que PoP soit soutenu par WordPress signifiait que Leonardo se trouvait dans une situation similaire à celle de nombreuses personnes incapables de faire certaines des choses disponibles dans un framework JavaScript. Comme il l'a noté :

PoP est construit sur WordPress. Cela signifie que de nombreuses techniques d'optimisation innovantes disponibles pour les frameworks Javascript, telles que le fractionnement de code à l'aide de Webpack ou de Service Workers via sw-precache, sont hors de portée (du moins sans une grande solution de contournement). En tant que telles, toutes les techniques d'optimisation décrites ci-dessous sont toutes du bricolage, conçues et mises en œuvre à partir de zéro.

Si vous souhaitez approfondir tous les détails de sa soumission, n'hésitez pas à le faire. Nous avons tous apprécié la lecture des détails des optimisations de Leonardo et avons estimé qu'il était un digne gagnant en raison de la quantité de travail nécessaire à cette entrée.

Toutes les soumissions

Nous avons été très satisfaits de la qualité des soumissions que nous avons reçues, et honnêtement, il n'a pas été facile de choisir un gagnant. Merci à tous ceux qui ont soumis - continuez votre excellent travail !

Jörgen Verweij

Jorgen Verweij a présenté une version optimisée du site Web de sa société Perplex Internetmarketing BV. Avec une équipe composée d'un UX'er, d'un développeur front-end, d'un développeur back-end et d'un administrateur système, il s'est lancé dans l'aventure de la performance.

Le résultat est une excellente mise en œuvre avec d'excellents résultats de perf dans tous les domaines : SpeedIndex bien en dessous de leur objectif fixé de 1250, un temps de chargement inférieur à 1 seconde, un démarrage du rendu en une demi-seconde, un PageSpeedscore de ¹⁰⁰ ⁄ ₁₀₀ et un audit Lighthouse presque parfait . Par rapport à l'ancienne situation, le temps de chargement est presque huit fois plus rapide. Gloire! Vous pouvez lire plus de détails sur le processus dans cet article complet rédigé par Jorgen.

Marco Hengstenberg

Marco Hengstenberg a soumis une version optimisée du site Web de l'agence de tourisme Land in Sicht . Pour améliorer les performances, Marco a utilisé pas mal de petites astuces et techniques astucieuses. Le préchargement de la feuille de style principale et le chargement critique des polices avec préchargement dans les navigateurs pris en charge ne sont que deux d'entre eux. Il a également restructuré le code HTML pour le rendre aussi plat, sémantique et accessible que possible et a réduit la quantité de données initialement transférées lors de la première visite de près de 3 Mo à 1,3 Mo sur le bureau (et en raison de l'utilisation d'images réactives pour l'image du héros, il est encore moindre que sur les écrans étroits).

Pour rationaliser encore plus le site, Marco a supprimé Bootstrap, jQuery et Modernizr, mis en place un processus de construction avec Grunt et introduit un ServiceWorker qui rend également le site disponible hors ligne. L'effort en valait la peine : le résultat est un TTL spectaculaire qui est passé de 32 secondes à 2 secondes et une diminution de près de 50 % des requêtes HTTP et des octets transférés (voir également le rapport Lighthouse, ZIP 251 Ko). Le préchargement et le rendu initial rapide aident tous les deux à percevoir le temps de chargement. Bon travail!

Gabriel Mariani

Le site Web du San Diego Christian College est celui auquel Gabriel Mariani a appliqué ses compétences en performance. Il a divisé le processus d'optimisation en quatre étapes. Tout d'abord, il a recadré toutes les images à la taille maximale dont elles avaient réellement besoin et en a créé des versions à l'échelle mobile. Il a ensuite fait toutes les images chargement paresseux. La deuxième étape s'est concentrée sur JavaScript et sur la suppression de tous les scripts en ligne fournis avec le site WordPress et son thème et plugins tiers. Ensuite, il a mis en file d'attente autant de scripts que possible afin qu'Autoptimize puisse les récupérer et les réduire/les combiner en un seul fichier.

Gabriel a également réduit le nombre de polices utilisées et configuré les polices Google pour qu'elles se chargent de manière async afin que le chemin critique CSS se charge en premier. Enfin et surtout, il a abordé d'autres petits problèmes comme la personnalisation des plugins WordPress, de sorte qu'ils s'appuient sur ajax au lieu de PHP. Cela lui a permis d'activer la mise en cache des pages et éventuellement d'activer un CDN pour le site. Un passage à HTTP/2 et HTTPS était la dernière étape. Voir WebPageTest pour les résultats complets. Agréable!

Alexandre Zargès

Alexander Zarges a développé Cloud Player, une application Web d'une seule page basée sur Angular 4 qui vous permet de rechercher et de lire des applications YouTube et SoundCloud. La version mise à niveau utilise le compilateur Angular à l'avance pour atteindre un temps d'initialisation d'environ 2,9 secondes (contre 5,2 secondes lors de l'utilisation du compilateur juste-à-temps). Si vous souhaitez approfondir le code, consultez le référentiel GitHub qui l'accompagne.

La raillerie de Bradly

Bradley Taunt a profité de notre défi pour expérimenter son site personnel. Comme base de son entreprise d'optimisation, il a utilisé sa page d'accueil et un article riche en images. Pour réduire les temps de chargement à 4,2 secondes pour l'article, Bradley utilise par défaut les polices du système d'exploitation de l'utilisateur au lieu d'utiliser des polices Web, entre autres.

Pour un coup de pouce supplémentaire, la version optimisée intègre également le CSS critique, sert des images réactives et utilise la mise en cache CDN. Vous pouvez obtenir un aperçu plus détaillé des coulisses dans le billet de blog que Bradley a écrit sur la façon dont il a relevé le défi.

Jean Beales

John Beales s'est lancé le défi d'améliorer les performances de 4RoadService.com. Quand il a commencé, il y avait déjà quelques optimisations en place. Les images statiques ont été exécutées via ImageOptim, par exemple, CSS et JS ont été minifiés, ils exécutaient un CDN via CloudFlare, et le site utilisait déjà un chargeur de style Single-Page-App afin que le nouveau contenu soit toujours récupéré par XHR et la page est jamais complètement redessiné.

Pour ce défi, John a activé l'optimisation des images et la compression WebP dans Cloudflare. Le site mis à jour utilise désormais HTTP/2 Server Push pour envoyer les principaux fichiers CSS et JS avec le chargement de page initial et s'appuie sur Guetzli pour la compression JPEG. Pour optimiser la mise en cache, il a mis à jour les URL de tous les actifs statiques afin que l'URL change chaque fois que l'actif change, puis a mis tous les actifs statiques en cache pendant un an. Pour une meilleure mise en cache des images, John a également mis à jour les URL des images redimensionnées dynamiquement afin que CloudFlare pense qu'il s'agit de fichiers image statiques.

Le résultat : la première peinture significative est passée de 2 220 ms à 1 290 ms et la première interactive de 5 480 ms à 3 040 ms. Vous pouvez voir les résultats complets des tests Lightbox et WebPage ici.

Shaun O'Connell

L'entrée de Shaun O'Connel était le travail qu'il a fait sur kiwi.ruby.nz. L'objectif était de transformer le site Web de la conférence en PWA afin que les participants à la conférence puissent rechercher toutes les informations concernant l'événement hors ligne. Certaines des choses qu'il a faites : remplacer un iframe Google Maps typique par Google Static Maps, auto-héberger des polices de sous-ensembles, déplacer CSS en ligne pour conserver la première demande sous 14 Ko, supprimer les dépendances, ajouter des Service Workers pré-cache et ajouter Turbolinks pour snappy transitions de pages. Ce faisant, le temps de rendu initial est passé de 3,9 secondes à 0,3 seconde.

Pour plus de détails, consultez les WebPageTests.

Ruslan Julbarissow

Ruslan Julbarissow a soumis son site personnel zerofy.de. Depuis qu'il a terminé son travail d'optimisation peu de temps avant la publication du concours, il n'y a malheureusement pas de résultats détaillés avant, mais Ruslan a fait une bonne description de la façon dont ses ajustements ont conduit à une taille de page de 1,6 Ko et un TTFB de 197 ms. Outre la mise en cache, la minification, GZIP et les ajustements jQuery, il charge ensuite les polices pour éviter le blocage du rendu, et en remplaçant FontAwesome par un ensemble IcoMoon personnalisé de 10 icônes, il a réussi à économiser 130 Ko supplémentaires.

Pour augmenter le score de l'indice de vitesse et obtenir l'expérience la plus rapide possible, il a également créé un fichier PHP séparé qui contient tous les styles CSS affectant la vue au-dessus de la ligne de flottaison. Un détail sympa : Le minuscule script Barba.js lui permet de créer des transitions de pages sans recharger tout le site.

Merci à tous pour votre participation

Phew! C'était tout un défi en effet ! Pour ceux d'entre vous qui aiment un si bon défi et un chatouillement cérébral de temps en temps, restez à l'écoute pour le prochain défi. Nous en proposerons un autre en un rien de temps, c'est sûr !