Catégories
Astuces et Design

Pourquoi nous avons déménagé un site vieux de 20 ans à Gatsby – SitePoint

Nous savions que nous avions un problème.

En 2019, SitePoint obtenait des scores de vitesse de phare inférieurs à 10 sur mobile et entre 20 et 30 sur ordinateur.

Nos efforts pour contrôler le gonflement UX ont échoué dans le sillage d'un environnement commercial de publication qui a provoqué de nouvelles fuites juste au moment où nous avions fini de brancher temporairement la dernière. Notre dépendance à l'égard de la publicité, contrôlée par des tiers, a été un obstacle majeur à l'amélioration des performances du site. La croissance de notre trafic s'est transformée en déclin.

Sur un site qui offrait aux gens un endroit où venir et apprendre à coder avec les meilleures pratiques, ce n'était pas une bonne idée. Et ce n'était pas non plus un site dont nous pouvions être fiers.

Pour aggraver les choses, des goulots d'étranglement opérationnels sont apparus qui ont fait de l'adaptation une entreprise logistique délicate. Notre équipe avait du mal à apporter des modifications au site: après avoir mis l'accent sur notre expérience Premium pendant plusieurs années, nous étions réduits à un développeur avec une expérience WordPress et PHP. Pour tester les modifications de code, l'équipe devrait attendre dans une file d'attente pour accéder à notre serveur de transfert.

Ce n’était un travail stimulant pour personne, et ce n’était certainement pas efficace.

Il était temps de faire quelques changements et nous nous sommes mis à chercher une solution. Après de nombreuses recherches, nous avons décidé que Gatsby conviendrait parfaitement à notre équipe. Cela profiterait à nos talents, nous aiderait à résoudre tous les problèmes que nous avions identifiés et nous permettrait de continuer à utiliser WordPress pour le backend afin que le processus éditorial n'ait pas besoin de changer.

Pourquoi nous avons déménagé à Gatsby

Refonte de SitePoint 2020

Le résultat final.

Au début du processus de recherche, Gatsby a commencé à ressembler à un précurseur sérieux. SitePoint n'est pas un petit site, nous savions donc que la technologie que nous avions choisie devait être capable de gérer des demandes assez intenses. Gatsby a coché toutes nos cases:

  • Nous pourrions tout coder dans React, une technologie que chaque membre de l'équipe frontale connaît et utilise quotidiennement.
  • Gatsby est super rapide dans son cœur – la performance était au cœur de ce projet, et nous pouvions partir d'un bon pied.
  • L'ensemble du site est rendu statique, ce qui serait parfait pour le référencement.
  • Nous pourrions le construire comme un nouveau projet, ce qui ne signifiait pas de souci pour la base de code existante, qui apportait une énorme quantité de code hérité avec.
  • Nous pourrions utiliser Gatsby Cloud, permettant à l'équipe d'obtenir des commentaires sur la construction à tout moment simplement en poussant la branche vers GitHub.
  • Les attaques DDoS sur WordPress ne nous poseraient pas de problème, car le front-end est complètement autonome.

CSS plus maintenable avec styled-components

Puisque nous allions reconstruire le site à partir de zéro, nous avions prévu de faire quelques changements de conception en même temps. Pour aider à ce travail, nous avons décidé d'utiliser des composants de style.

styled-components maintient le style du site facile à entretenir, et nous savons où chercher lorsque nous voulons changer le style de quelque chose – le style est toujours avec le composant.

Comment nous avons réalisé la construction

Nous avons commencé par suivre les documents de base de Gatsby et insérer nos messages avec le gatsby-source-wordpress brancher.

Ce fut un gros test initial pour nous: il fallait voir si c'était encore possible d'utiliser Gatsby pour notre site.

Après 20 ans de blogs, nous avons publié plus de 17 000 articles. Nous savions que les versions prendraient beaucoup de temps, mais nous devions savoir si Gatsby pouvait gérer une telle quantité de contenu. Comme vous l’avez probablement compris, le test a apporté de bonnes nouvelles: Gatsby fonctionne.

Un petit conseil pour les autres équipes travaillant sur de grands sites: pour faire du développement une meilleure expérience, nous avons utilisé des variables d'environnement pour empêcher Gatsby d'aller chercher tout des publications du site en développement. Rien de tel qu'une recharge à chaud de 60 minutes pour ralentir la progression.

if (hasNextPage && process.env.NODE_ENV != "development") {
  return fetchPosts({ first: 100, after: endCursor });
}

À partir de ce moment, nous avons rencontré certaines limitations avec le plugin source WordPress. Nous n'avons pas pu obtenir toutes les données dont nous avions besoin, nous sommes donc passés au plugin WordPress GraphQL.

Nous utilisons Yoast pour définir nos métadonnées pour le référencement, et nous devions nous assurer que nous récupérions les informations correctes. Nous avons pu le faire avec WordPress GraphQL. En procédant de cette façon, l'équipe de contenu pourrait toujours modifier les métadonnées de la même manière, et les données seraient toujours dynamiques et récupérées sur chaque build.

Pendant la construction, nous aurions trois ou quatre personnes dans l'équipe travaillant sur des parties du nouveau blog. Dans le passé, s'ils voulaient obtenir des commentaires, ils devaient pousser vers notre serveur de transfert et s'assurer que personne ne l'utilisait déjà.

Nous avons constaté que Gatsby Cloud était une excellente solution à ce problème. Maintenant, quand quelqu'un pousse vers une branche dans GitHub, il crée une build dans Gatsby Cloud avec un lien de prévisualisation. Nos développeurs pourraient partager ce lien et obtenir des tests et des commentaires immédiats beaucoup plus efficacement qu'auparavant.

Ce cycle de rétroaction plus rapide a facilité la présence de plusieurs personnes au sein de l'équipe et a mis fin à un goulot d'étranglement majeur.

Launch Day Fun

Le jour J, nous avons lancé le nouveau site et effectué nos premiers tests. Le nouveau blog a été en volant – chaque chargement de page est ressenti instantanément.

Nous avons rencontré des problèmes sur SitePoint Premium, qui ont commencé à ralentir et même à planter. Le coupable était un nouvel élément sur les pages de blog qui a attiré les livres populaires que les gens lisaient actuellement. Il le ferait via un appel d'API côté client, et c'était trop pour Premium à gérer en raison de la quantité de trafic que nous obtenons du côté du blog.

Nous avons rapidement ajouté une mise en cache de pages à l'API pour résoudre temporairement les problèmes. Nous avons réalisé que nous faisions cela de manière incorrecte – nous aurions dû nous procurer ces données au moment de la construction, de sorte que les livres populaires soient déjà chargés lorsque nous servons la page à l'utilisateur.

C'est le principal changement de mentalité que vous devez faire lors de l'utilisation de Gatsby: toutes les données que vous pouvez obtenir au moment de la construction doivent être récupérées au moment de la construction. Vous ne devez utiliser les appels d'API côté client que lorsque vous avez besoin de données en direct.

Une fois que nous avons réécrit l'appel de l'API pour qu'il se produise pendant la génération, le premier chargement d'une page de blog était encore plus rapide – et Premium a cessé de planter.

Ce que nous devons encore résoudre

Bien qu'il soit difficile d'exagérer à quel point notre expérience sur site est meilleure aujourd'hui, il nous reste encore quelques points douloureux à résoudre.

Si un nouvel article est publié ou si le contenu est mis à jour – comme c'est plusieurs fois par jour – nous devons réexécuter la version Gatsby avant que ces changements n'apparaissent.

Notre solution pour le moment est une tâche cron simple qui s'exécute à des heures préprogrammées au cours d'une journée. La solution à long terme à cela consiste à ajouter un webhook au bouton de publication et de mise à jour de WordPress, afin qu'une nouvelle version soit déclenchée une fois enfoncée.

Nous devons également exécuter des versions incrémentielles. À l'heure actuelle, le site entier doit être reconstruit à chaque fois, et compte tenu de nos archives de contenu, cela peut prendre un certain temps. Gatsby vient d'introduire des versions incrémentielles au fur et à mesure de notre mise en ligne, et nous travaillons à l'implémenter sur notre site. Une fois cette configuration effectuée, nos versions seront beaucoup plus rapides si la seule chose qui a changé est le contenu.

Notre score de vitesse n'est toujours pas là où nous le voulons. Bien que le site soit subjectivement très rapide, nous n'obtenons toujours pas de scores cohérents dans Lighthouse. Nous souhaitons placer le mobile et le bureau dans la zone verte (scores de 90+) pour une expérience utilisateur et un référencement optimaux.

Le ferions-nous encore?

Un lancement de ce type serait normalement un événement assez éprouvant pour les nerfs et demanderait beaucoup de travail à l'équipe le jour du lancement.

Avec Gatsby, notre lancement a été vraiment facile. Nous avons juste dû déplacer WordPress sur un nouveau domaine et pointer sitepoint.com sur la version Gatsby du site.

Ensuite, nous nous sommes assis et avons regardé les chiffres pour voir ce qui était arrivé à notre trafic. En quelques jours, les données commençaient à arriver et nous assistions à une augmentation de 15% du trafic. Les mesures d'engagement des utilisateurs étaient en hausse dans tous les domaines.

Il n’est pas difficile de comprendre pourquoi les effets ont été si immédiats. Nous avions un meilleur référencement fonctionnant sur des pages HTML et CSS statiques, et des améliorations massives de la vitesse rendues possibles par le passage à Gatsby.

Depuis que nous avons fait le pas, nous avons augmenté nos scores de vitesse de phare de 6-15 sur mobile à la gamme 50-60, et des années 30 sur ordinateur de bureau dans les années 70. Nous voulions nous assurer que la vitesse restait la priorité avec ce changement. Nous utilisons donc un excellent outil appelé Calibre qui exécute des tests de vitesse sur plusieurs pages de haut niveau chaque jour et nous avertit des résultats. Nous utilisons cet outil pour continuer à améliorer notre score, donc j'espère avoir un autre article pour vous dans trois mois lorsque nous aurons tout pour rester dans la gamme 90+.

L'équipe adore travailler à Gatsby. La base de code du blog était quelque chose sur laquelle personne ne voulait travailler. Maintenant, tout le monde veut prendre ces cartes grâce à la grande expérience des développeurs.

Si vous envisagez de déménager à Gatsby et que vous vous demandez s'il est prêt pour les heures de grande écoute, suivez nos conseils – cela vaut la peine d'être changé.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *