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

Au début du processus de recherche, Gatsby a commencé à ressembler à un chef de file 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 – les performances étaient au cœur de ce projet, et nous pourrions partir d'un bon pied.
• L'ensemble du site est rendu statique, ce qui serait formidable pour le référencement.
• Nous pourrions le construire comme un nouveau projet, ce qui signifiait ne vous inquiétez pas de la base de code existante, qui a apporté une énorme quantité de code hérité avec elle.
• 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 causeraient pas de problèmes, car le front-end est complètement autonome.

CSS plus maintenable avec composants de style

Puisque nous allions reconstruire le site à partir de zéro, nous prévu d'apporter quelques modifications de conception en même temps. Pour aider à ce travail, nous avons décidé d'utiliser styled-components .

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

Comment nous avons fait la construction se produire

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

a été un gros test initial pour nous: nous avons dû voir s'il était 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 de récupérer toutes des postes du site en développement. Il n'y a rien de tel qu'un rechargement à chaud de 60 minutes pour ralentir la progression.

 if (hasNextPage && process.env.NODE_ENV! = "Development") {
  return fetchPosts ({premier: 100, après: endCursor});
}

À partir de là, 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 avons donc opté pour le 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 tirions les bonnes informations . 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 build, 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 pouvaient partager ce lien et obtenir des tests et des retours d'informations immédiats beaucoup plus efficacement qu'auparavant.

Ce cycle de feedback plus rapide a permis à plusieurs personnes de travailler sur la construction et à mettre fin à un goulot d'étranglement majeur. [19659032] Launch Day Fun

Le jour J, nous avons lancé le nouveau site et effectué nos premiers tests. Le nouveau blog volait – chaque chargement de page se faisait sentir instantanément.

Nous avons rencontré des problèmes sur SitePoint Premium, qui a 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 des pages à l'API pour résoudre temporairement le problème. 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 création, 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 lorsque en utilisant 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 d'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 – car il est plusieurs fois par jour – nous devons réexécuter la version Gatsby avant que ces changements n'apparaissent.

Notre solution pour cela en ce moment est une simple tâche cron 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, de sorte qu'une nouvelle version soit déclenchée une fois pressé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 voulons mettre à la fois 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 assez éprouvant pour les nerfs événement, et prendre beaucoup de travail de l'équipe le jour du lancement.

Avec Gatsby, notre lancement a été vraiment facile. Nous avons juste eu à déplacer WordPress sur un nouveau domaine et à pointer sitepoint.com vers 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 ont augmenté 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 déménagé, nous avons augmenté nos scores de vitesse du phare de 6-15 sur mobile au 50. -60 gamme, et des années 30 sur le 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 un certain nombre de 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 quand nous aurons tout pour rester dans la gamme 90+.

L'équipe aime 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é.