Migration de WordPress vers JAMStack

( Ceci est un article sponsorisé. ) Chaque fois que les développeurs parlent de WordPress, de leur variation du pourcentage de part de marché. " 20% de tous les sites sont sur WordPress! " " 40% de tous les sites sont sur WordPress! " Quel que soit le pourcentage, le message est le même: en termes d'adoption, WordPress est MASSIVE.

Alors pourquoi, avec ce type d'adoption, un site qui utilise WordPress envisagerait-il de passer à JAMstack? Dans cette série d'articles en deux parties, nous couvrirons à quoi ressemble une migration WordPress réelle, en utilisant une étude de cas du site même que vous lisez en ce moment.

Nous parlerons des gains et des pertes, du des choses que nous aimerions savoir plus tôt et ce qui nous a surpris. Et puis nous le suivrons avec une démonstration technique d'un chemin de migration possible, pas complètement hors de WordPress, mais comment vous pouvez servir WordPress découplé afin que vous puissiez avoir le meilleur des deux mondes: une implémentation JAMstack de WordPress qui vous donne tout la puissance de leur tableau de bord et de leurs fonctionnalités, avec de meilleures performances et sécurité.

Creusons!

Pourquoi?

En 2015, Netlify co-fondateur Mathias Biilmann et Smashing fondateur Vitaly Friedman ont parlé boutique. Comme l'architecture JAMStack a commencé à faire des tours, Smashing s'est davantage intéressé à l'idée de la pile. Vitaly et Markus (ancien directeur général de Smashing) ont demandé à Matt ce qui se passerait si Smashing migrait de leur site WordPress / LAMPstack traditionnel vers une architecture JAMstack.

À titre expérimental, Matt a gratté tout le code HTML de Smashing et l'a hébergé sur Netlify, livraison statique du contenu à partir d'un CDN. Les résultats étaient convaincants – la version statique est plus de six fois plus rapide en moyenne!

Ce type d'architecture fonctionne si bien en partie parce que les pages ne sont pas compilées à la demande lorsque vous les visitez . Puisque vous diffusez du contenu préconstruit directement à partir d'un réseau de diffusion de contenu le site est déjà «là» et prêt pour l'utilisateur.

Puisque vous diffusez via CDN, vous pouvez également distribuer le contenu à travers le monde – plus proche des visiteurs potentiels. Il n'y a pas de point d'origine central, ce qui est vital dans le cas de toute publication en ligne qui veut être rapide pour tous ses lecteurs.

La scène était donc prête. Smashing Magazine a migré vers JAMstack – vers Netlify en tant que plateforme en particulier. Au cours de ses 10 années d'exploitation, Smashing était passé d'une petite publication en ligne à un énorme blog WordPress, vendant des choses comme des livres, des billets de conférence et des ateliers.

Il y avait quelques morceaux de ce site:

• Blog WordPress [19659018] Tableau des emplois Rails
• Magasin Shopify
• Un autre CMS pour le site de la conférence

Lorsque Netlify a commencé la migration, le site souffrait de problèmes de performances, alourdis par 20 000 commentaires et des milliers d'articles. Smashing était également intéressé par l'authentification dans le cadre d'un nouveau plan d'abonnement, ainsi que par une refonte pour un look plus moderne.

Fiabilité

Smashing réalise régulièrement ce dont rêvent les autres plates-formes: des articles partagés largement par une énorme communauté. Cependant, lorsqu'un point de virilité a été atteint pour un poste, Smashing a régulièrement eu des problèmes avec les pannes. Pour atténuer cela, l'utilisation intensive des plugins WordPress a été introduite dans leur pile, mais ils ont toujours eu du mal à conserver de bonnes mesures de disponibilité.

Le passage à Netlify a permis à l'équipe Smashing d'éviter les erreurs de connexion à la base de données et de ne pas se soucier des temps d'arrêt même lorsqu'un article a vu un trafic énorme. Pourquoi? Parce que lors de la diffusion sans serveur, le contenu préconstruit n'a pas besoin d'être généré et diffusé – il existe déjà, prêt à être consulté. Rien n'est demandé sur place à l'exception de la page statique entière.

Servir via CDN a également permis à Smashing de dormir un peu plus facilement en termes de sécurité. wp-login.php est depuis longtemps une source de failles de sécurité et de vecteurs d'attaque. Le contenu prédéfini n'est pas accessible de la même manière et les failles de sécurité ne sont pas aussi omniprésentes.

Invalidation du cache

Smashing avait parcouru chaque plugin de mise en cache WordPress, avec des résultats variés et beaucoup de problèmes. Vitaly Friedman de Smashing mentionne,

«Les principaux problèmes que nous avions étaient liés à« Erreur lors de l'établissement de la connexion à la base de données »que nous continuions d'avoir toutes les deux semaines, et nous avons littéralement essayé tous les plugins de mise en cache WordPress. La performance était assez bonne (dans l'ensemble), mais nous cherchions à l'améliorer davantage. De plus, nous voulions lancer Membership et connecter toutes les différentes offres – conférences, offres d'emploi, articles, livres, livres électroniques – avec une seule plate-forme, et c'était remarquablement difficile à réaliser avec WordPress en jeu. »

Passer à Netlify a permis à l'équipe Smashing de voir une invalidation instantanée du cache tout en servant également du contenu mis en cache et performant, sans surcharge supplémentaire.

Lorsque vous déployez un site, les fichiers HTML sont hébergés sur le CDN de Netlify. Il est optimisé pour un taux d'accès au cache élevé et un délai de premier octet rapide, tout en pouvant invalider instantanément tous les fichiers HTML qui ont changé. Netlify empreinte également tous les liens vers des actifs tels que des fichiers CSS, des images, des polices ou des fichiers JS, et sert Smashing avec des en-têtes de mise en cache qui les mettent en cache pour toujours. Les empreintes digitales garantissent qu'elles sont uniques et que si vous mettez à jour une nouvelle version, la version la plus récente est servie à la place.

Workflow

En regardant la configuration existante, une des principales raisons de la migration était simplement d'unifier les propriétés existantes . Le fait de devoir changer de contexte entre toutes ces différentes piles et configurations technologiques est devenu un problème de maintenance difficile qui a exigé les ingénieurs.

Quand auparavant leur infrastructure était divisée entre tant de systèmes différents, ce processus de migration a également tout unifié en gardant le site principal, le site de la conférence, les abonnements et la section e-commerce fonctionnant ensemble au lieu d'être gérés séparément avec des piles différentes. Cela a permis de maintenir des coûts de développement bas et une expérience de développement constante sur toutes les propriétés.

La pièce de migration WordPress s'est avérée être la plus grande et la plus délicate. Netlify a essayé d'exporter les données de l'exportateur WP, seulement pour découvrir que le contenu avait des incorporations qui devaient être préservées, ou parfois modifiées par des plugins. Afin de maintenir la parité avec ce qui était sur le site, une série de grattoirs a été écrite, ventilée par articles, actifs, commentaires et page d'accueil.

Une fois que cela a été écrit et transformé, il a été chargé dans un nouveau référentiel en GitHub et CMS Netlify ont été utilisés à la place. Ce qui rend le CMS Netlify unique, c'est qu'il est léger et intègre les éditeurs de contenu dans un flux de travail Git – ce qui signifie qu'il extraira et servira littéralement les fichiers de démarques à partir d'un référentiel git au lieu d'une base de données. De plus, Netlify CMS est indépendant de la plate-forme et fonctionne avec (presque) tous les générateurs de sites statiques et les sites stockés dans GitHub.

leur refonte. Elle a créé une bibliothèque de composants pour construire l'architecture frontale et a remarqué à quel point il était plus simple de travailler avec car elle travaillait directement dans git, même lorsqu'elle travaillait avec le CMS.

«Tout ce que j'ai poussé vers le Le référentiel est directement appliqué à la bibliothèque de modèles, ce qui signifie que vous n'avez pas à gérer deux ensembles de composants différents … ce type de continuité était génial! Tout ce que j'ai à faire est d'écrire du HTML, du CSS et du JavaScript et de pousser vers le repo et tout fonctionne comme par magie. Le flux de travail était fantastique. »

Tout cela étant dit, le CMS Netlify peut parfois être trop léger pour un tel cas d'utilisation à fort trafic et à grande échelle. Smashing a régulièrement des auteurs invités et une équipe éditoriale complète. Certaines des riches fonctionnalités de WordPress sont vraiment utiles pour ce type d'environnements hautement collaboratifs.

C'est pourquoi dans le didacticiel suivant, nous vous expliquerons un modèle sans tête où vous pouvez toujours récolter les avantages du tableau de bord WordPress pour les créateurs de contenu, mais utilisez WordPress via l'API et faites en sorte que le développement repose sur un flux de travail git-centric facile à maintenir pour les développeurs. Restez à l'écoute!

Choix de frameworks

Dans le prototype initial que Matt Biilmann a créé, il a tout écrit dans Preact minimal, associé à Hugo, car il était très concentré sur la performance. Il a juste utilisé des accessoires et a gardé tout très léger. En faisant passer le projet pour être maintenu par le développeur de Smashing, Ilya Pukhalski, il a constaté que Preact manquait de certaines fonctionnalités qui lui manquaient pour puiser dans l'écosystème de React. Finalement, les avantages de Redux et d'autres bibliothèques ont dépassé le coût.

Réfléchissant maintenant, Matt dit qu'il aurait utilisé Vue, qui n'avait pas tout à fait la part de marché à l'époque (je jure que je ne l'ai pas invité à dire cette). J'ai posé la question évidente: pourquoi pas Svelte? Comme les gens soucieux de la performance ont tendance à atteindre cette bibliothèque. Il a mentionné que Svelte n'avait pas encore l'écosystème que Vue avait encore.

Quand Matt réfléchit à la question de savoir s'il aurait ou non encore utilisé Hugo, il dit qu'il aime Hugo, mais ce qu'il a trouvé difficile pour ce projet en particulier était qu'il n'avait pas assez d'un système de plugin – créer des bannières publicitaires et des choses de cette nature n'était pas assez programmable avec Hugo et il avait besoin d'injecter des scripts pour l'accomplir. Ces scripts avaient tendance à ralentir le processus de génération. Cela dit, nous utilisons toujours Hugo pour notre propre site à netlify.com et nous l'adorons – cette mise en garde est extrêmement particulière aux besoins du site de Smashing en particulier.

S'il pouvait le refaire, il pourrait choisir Eleventy, qui possède de riches capacités en termes de création de plugins et d'autres scripts extensibles. Ou, s'il utilisait Vue, Nuxt lui aurait offert de belles capacités de plugin tout en permettant d'être un bon choix pour ce framework, offrant un rendu côté serveur, un routage et une génération statique.

Construire de grands sites

Il y avait un problème qui est apparu en travaillant avec un site aussi grand que Smashing et peut-être que vous pouvez déjà comprendre de quoi il s'agit, nous l'avons juste abordé. Il est vrai qu'avec tout grand site de pages prédéfinies servies sur un CDN, les performances sont toujours excellentes car nous ne construisons rien à la volée pour les utilisateurs.

Mais cet avantage ne peut se produire que si le site est préconstruit et ce processus peut prendre du temps. Bien que des sites plus traditionnels créent les pages lorsque vous en faites la demande, nous créons littéralement chaque page à l'avance au cas où l'utilisateur en aurait besoin. Cela rend les performances super rapides! Mais ce temps est maintenant déchargé sur le temps de développement et de publication – la création de chaque page peut prendre du temps.

Ce n'est pas vraiment un problème avec les petits sites, mais à l'échelle de Smashing Magazine, nous devons penser à ce temps un peu plus. , en particulier pour que les gens puissent maintenir une productivité élevée tout en créant activement du contenu quotidiennement.

Netlify a créé un grand dossier / production-articles qui contenait la majeure partie des milliers d'articles qu'il hébergeait déjà. . Ensuite, créé un répertoire de travail distinct appelé contenu / articles où les articles qui étaient activement créés et modifiés pouvaient être placés.

Ce processus de construction signifiait que tous ceux qui travaillaient sur le site travaillaient avec un petit lot d'articles pour le développement local, sans entrave en attendant la construction entière. Ce processus a été géré par une tâche complexe pour préparer les articles de production, et a libéré Hugo pour qu'il ne gère que ce qui était activement travaillé.

L'un des inconvénients de cette approche est qu'elle nécessite toujours l'exécution de l'intégralité de la génération. , ce qui ralentit le processus. Dans une publication plus petite, cela aurait probablement moins d'importance, mais à l'échelle de Smashing, cela ralentit le processus de publication.

API Open Source

Au début, nous avons mentionné qu'entre autres choses, Smashing souhaitait migrer leur solution de commerce électronique existante, gérez les commentaires en dehors de WordPress et ajoutez des fonctionnalités d'authentification. Toutes ces fonctionnalités ont été construites avec des solutions open source que Netlify maintient, les transformant en API sans état:

• GoTell
  Un API et un outil de construction pour gérer de grandes quantités de commentaires.
• GoCommerce
  Une petite API basée sur Go pour les sites de commerce électronique qui gère les commandes et les paiements.
• GoTrue
  Une petite API open-source écrite en Golang qui peut agir en tant que autonome Service API pour gérer l'enregistrement des utilisateurs et l'authentification des projets. Il est basé sur OAuth2 et JWT et gérera l'inscription des utilisateurs, l'authentification et les données utilisateur personnalisées.

Chacun de ces éléments nécessitait une migration et des facteurs uniques, et bien qu'ils soient hors de portée pour cet article, ils ' re tous couverts dans un livre gratuit que Matt a co-écrit intitulé " Développement Web Moderne sur le JAMstack ". Nous ferons également des plongées approfondies comme celle-ci – avec des exemples utilisables – dans la recherche et l'authentification, dans les articles suivants.

Conclusion

La migration s'est déroulée sans heurts. Fracassant? Euh… ça s'est bien passé. Smashing n'était pas pénalisé pour son propre succès – lorsqu'un article populaire arrivait, il pouvait servir le contenu de manière cohérente, sans plus écoper de charges importantes. Parallèlement à cela, le passage à une infrastructure JAMstack a amélioré les performances et la sécurité.

Markus Seyfferth, ancien PDG de Smashing Magazine, a déclaré:

«Le temps de chargement initial est tellement plus rapide qu'auparavant… avant que nous devions attendez que le fichier HTML soit servi pendant 800 ms et maintenant c'est 80 ms . »

Ce processus a réussi et comme tout grand projet d'ingénierie, des leçons ont été apprises en cours de route. Dans le prochain article de cette série, nous allons parcourir un didacticiel et une démonstration de ce que nous recommanderions compte tenu de ce que nous avons appris. Si vous souhaitez moderniser votre développement WordPress et profiter des avantages de JAMstack en termes de performances et de sécurité, lisez la suite!

(ra, vf, il)