Comment Smashing Magazine gère le contenu : migration de WordPress vers JAMstack

Cet article a été aimablement soutenu par nos chers amis de Netlify, une plate-forme tout-en-un pour automatiser les projets Web modernes. Merci!

Chaque fois que les développeurs parlent de WordPress, leur pourcentage de part de marché change. “ 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 MASSIF.

Alors pourquoi, avec ce type d'adoption, un site utilisant WordPress envisagerait-il de passer à JAMstack ? Dans cette série d'articles en deux parties, nous expliquerons à 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, des choses que nous aurions aimé savoir plus tôt et de ce qui nous a surpris. Et puis nous 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 une meilleure sécurité.

Allons creuser !

Pourquoi?

En 2015, le co-fondateur de Netlify, Mathias Biilmann, et le fondateur de Smashing, Vitaly Friedman, ont parlé boutique. Alors que l'architecture JAMstack commençait à 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 récupéré tout le code HTML de Smashing et l'a hébergé sur Netlify, diffusant le contenu de manière statique à partir d'un CDN. Les résultats ont été 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. Étant donné que vous diffusez du contenu prédéfini directement à partir d'un réseau de diffusion de contenu , le site est déjà « là » et prêt pour l'utilisateur.

Puisque vous servez via CDN, vous pouvez également distribuer le contenu à travers le monde - plus près 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 se veut rapide pour tous ses lecteurs.

Le décor était donc planté. Smashing Magazine a migré vers JAMstack - vers Netlify en tant que plate-forme en particulier. Au cours de ses 10 années d'activité, Smashing est 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:

• WordPressblog
• Tableau des emplois Rails
• Boutique 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, alourdi par 20 000 commentaires et des milliers d'articles. Smashing s'est également intéressé à l'authentification dans le cadre d'un nouveau plan d'abonnement, ainsi qu'à une refonte pour un look plus moderne.

Fiabilité

Smashing réalise régulièrement ce dont rêvent les autres plateformes : des articles largement partagés par une énorme communauté. Cependant, lorsqu'un point de basculement du trafic était atteint pour un poste, Smashing rencontrait régulièrement des problèmes de pannes. Pour atténuer cela, l'utilisation intensive des plugins WordPress a été introduite dans leur pile, mais ils ont encore du mal à conserver de bonnes métriques 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 s'inquiéter des temps d'arrêt , même lorsqu'un article a vu une énorme quantité de trafic. Pourquoi? Parce que lors de la diffusion sans serveur, le contenu prédéfini n'a pas besoin d'être généré et diffusé - il existe déjà, prêt à être visualisé. Rien n'est demandé sur place, à l'exception de la totalité de la page statique.

Servir via CDN a également permis à Smashing de dormir un peu plus facilement en termes de sécurité. wp-login.php a longtemps été 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 tous les plugins 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 rencontrions toutes les deux semaines, et nous avons littéralement essayé tous les plugins de mise en cache WordPress. Les performances étaient plutôt correctes (dans l'ensemble), mais nous cherchions à les améliorer davantage. De plus, nous voulions lancer l'adhésion 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. "

Le passage à Netlify a permis à l'équipe Smashing de voir l'invalidation instantanée du cache tout en servant 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 d'obtention rapide du premier octet, tout en étant capable d' invalider instantanément tous les fichiers HTML qui ont été modifiés. Netlify enregistre é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. L'empreinte digitale garantit qu'ils sont uniques et que si vous mettez à jour une nouvelle version, la version la plus récente est servie à la place.

Flux de travail

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

Alors qu'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 travaillant ensemble au lieu d'être maintenus séparément avec différentes piles. Cela a permis de maintenir les coûts de développement bas et l'expérience des développeurs travaillant sur toutes les propriétés de manière cohérente.

La pièce de migration WordPress s'est avérée être la plus importante et la plus délicate. Netlify a essayé d'exporter les données de l'exportateur WP, seulement pour constater que le contenu avait des intégrations qui devaient être préservées, ou parfois modifiées par des plugins. Afin de maintenir la parité avec ce qui se trouvait 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 dans GitHub, et Netlify CMS a été utilisé à la place. Ce qui rend Netlify CMS unique, c'est qu'il est léger et intègre des éditeurs de contenu dans un flux de travail Git, ce qui signifie qu'il extraira et servira littéralement des fichiers de démarquage à 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.

À cette époque, Sara Soueidan travaillait pour Smashing en tant que développeur front-end indépendant sur 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 référentiel est directement appliqué à la bibliothèque de modèles, ce qui signifie que vous n'avez pas à maintenir deux ensembles de composants différents... ce type de continuité était génial ! Tout ce que j'ai à faire est d'écrire HTML, CSS et JavaScript et de pousser vers le référentiel et tout fonctionne comme par magie. Le flux de travail était fantastique.

Cela dit, Netlify CMS peut parfois être trop léger pour un cas d'utilisation aussi important et à grande échelle. Smashing a régulièrement des auteurs invités et une équipe éditoriale complète. Certaines des fonctionnalités riches offertes par WordPress sont vraiment utiles pour ces types d'environnements hautement collaboratifs.

C'est pourquoi, dans le didacticiel suivant, nous vous guiderons à travers un modèle sans tête , où vous pouvez toujours profiter des 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 s'appuie sur un flux de travail centré sur git aussi simple pour les développeurs à maintenir également. Restez à l'écoute!

Choix de cadre

Dans le prototype initial que Matt Biilmann a créé, il a tout écrit en Preact minimal, jumelé avec Hugo, car il était très concentré sur la performance. Il a juste utilisé des accessoires et a gardé tout très léger. Alors qu'il confiait le projet à la maintenance du développeur de Smashing, Ilya Pukhalski, il a découvert que Preact manquait de certaines fonctionnalités qui lui manquaient pour exploiter l'écosystème de React. Finalement, les avantages de Redux et d'autres bibliothèques ont dépassé le coût.

En 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 incité à dire cela). J'ai posé la question évidente : pourquoi pas Svelte ? Comme les gens soucieux de la performance ont tendance à rechercher cette bibliothèque. Il a mentionné que Svelte n'a pas encore tout à fait l'écosystème de Vue.

Lorsque Matt se demande s'il aurait encore utilisé Hugo ou non, il dit qu'il aime Hugo, mais ce qu'il a trouvé difficile pour ce projet en particulier, c'est qu'il n'avait pas assez de système de plug-in - 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 construction. Cela dit, nous utilisons toujours Hugo pour notre propre site sur 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 soit 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 fonctionnalités de plug-in 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 ce que c'est, nous venons de l'aborder. Il est vrai qu'avec n'importe quel 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. Alors que les sites plus traditionnels construiront les pages lorsque vous les demanderez, nous créons littéralement chaque page à l'avance au cas où l'utilisateur en aurait besoin. Cela rend la performance super rapide! Mais ce temps est maintenant consacré au 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 réfléchir un peu plus à ce temps, en particulier pour que les gens puissent maintenir une productivité élevée tout en créant activement du contenu quotidiennement.

Ce que Netlify a fait, c'est créer un grand dossier /production-articles qui contient l'essentiel des milliers d'articles qu'ils hébergent déjà. Ensuite, créé un répertoire de travail séparé appelé content/articles où les articles qui étaient activement créés et édités pouvaient être placés.

Ce processus de construction signifiait que tous ceux qui travaillaient sur le site travaillaient avec un plus petit lot d'articles pour le développement local, sans être gênés par l'attente de la construction entière. Ce processus a été géré par une tâche gulp pour préparer les articles de production, et a libéré Hugo pour qu'il ne s'occupe que de ce sur quoi il travaillait activement.

L'un des inconvénients de cette approche est qu'elle nécessite toujours l'exécution de la construction entière, 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, Smashing souhaitait migrer sa solution de commerce électronique existante, gérer les commentaires en dehors de WordPress et ajouter des fonctionnalités d'authentification. Toutes ces fonctionnalités ont été construites avec des solutions open source gérées par Netlify, les décomposant en API sans état :

• GoTell
  Une 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 comme un service d'API autonome pour gérer l'enregistrement et l'authentification des utilisateurs pour les projets. Il est basé sur OAuth2 et JWT et gérera l'inscription des utilisateurs, l'authentification et les données utilisateur personnalisées.

Chacune de ces pièces nécessitait une migration et des facteurs uniques, et bien qu'elles soient hors de portée de cet article, elles sont toutes couvertes dans un livre gratuit co-écrit par Matt intitulé " Modern Web Development on the 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 à merveille. Écrasant ? Euh... ça s'est bien passé. Smashing n'a pas été pénalisé pour son propre succès - lorsqu'un article populaire est arrivé, ils pouvaient diffuser le contenu de manière cohérente, sans plus renoncer à de grosses charges. 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 premier chargement est tellement plus rapide qu'auparavant… avant, nous devions attendre que le fichier HTML soit servi pendant 800 ms et maintenant c'est 80 ms ."

Ce processus a été couronné de succès et, comme tout grand projet d'ingénierie, des leçons ont été apprises en cours de route. Dans ce 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 performance et de sécurité de JAMstack, lisez la suite !