Headless WordPress : qu'est-ce que c'est et en avez-vous besoin ?

Chez Managed Server, nous sommes de grands partisans de WordPress et de son écosystème. Nous l'utilisons également pour nos sites car nous trouvons vraiment que c'est le meilleur système de gestion de contenu, car les statistiques continuent de s'afficher année après année. Il est open source, polyvalent et, en un mot, il est incroyablement facile de comprendre pourquoi il alimente plus de 40 % de tous les sites Web sur Internet.

Avec la taille de l'écosystème et de la communauté de développeurs autour de WordPress, il n'est pas surprenant que les gens utilisent WordPress de différentes manières. L'une de ces approches consiste à utiliser WordPress comme un CMS sans tête, en abrégé, nommé WordPress sans tête, qui devient de plus en plus populaire.

Dans ce guide, nous détaillerons tout ce que vous devez savoir sur WordPress Headless, ses avantages, ses inconvénients et plus encore grâce à l'expérience de première main de notre équipe.

Qu'est-ce que WordPress sans tête ?

Pour comprendre WordPress Headless, vous devez savoir ce qu'est WordPress monolithique. Monolithique, o WordPress dans sa forme traditionnelle, c'est WordPress tel que vous le connaissez. Il s'agit d'un système de gestion de contenu que vous pouvez utiliser pour gérer tout le contenu de votre site.

En général, WordPress a le backend (le système de gestion de contenu) et la couche de présentation, qui vous permet de concevoir votre site Web. Cependant, les sites Headless WordPress sont ceux qui s'appuient simplement sur WordPress comme système de gestion de contenu et utilisent une pile frontale différente pour afficher le contenu.

Cela permet une plus grande flexibilité en termes de développement. Fondamentalement, avec l'aide de l'API REST, vous pouvez utiliser WordPress pour sa fonctionnalité de gestion de contenu en l'associant à une interface créée séparément dans un cadre comme Vue.js o Réagir (pour n'en nommer que quelques-uns, il existe une multitude d'autres frameworks et outils frontaux disponibles).

WordPress est considéré comme une architecture CMS couplée car tous les outils d'édition frontaux et les fonctionnalités de gestion de contenu (édition) back-end sont couplés. Cela permet aux équipes de développeurs, d'éditeurs, de rédacteurs, etc. de gérer à la fois la couche de présentation et le contenu. Contrairement aux sites Web Headless WordPress qui suivent une architecture découplée où la couche de présentation et le contenu sont, comme son nom l'indique, découplés.

REST, GraphQL et intégration de fichiers plats

Une configuration CMS sans tête utilise des API et des CDN pour restituer le contenu. Et il existe actuellement trois options : l'API REST, l'intégration de fichiers plats et GraphQL.

WordPress utilise l'API REST pour vous permettre de connecter l'interface au CMS. Une API REST est simplement une interface de programmation d'application qui suit les contraintes de l'architecture REST, fournissant une interface uniforme qui permet aux serveurs et aux clients de transférer des données entre eux. REST permet aux développeurs d'exposer et d'utiliser des données spécifiques, si le point de terminaison REST n'a pas les données directement disponibles, un développement supplémentaire sera nécessaire.

Une autre alternative est GraphQL (QL est l'abréviation de Query Language). GraphQL facilite l'interrogation des API avec des champs et des relations spécifiques, comme vous le feriez avec une base de données. Il s'agit d'une amélioration significative et il existe un plug-in qui le rend une API GraphQL disponible sur WordPress . Cela peut signifier qu'aucun développement supplémentaire n'est nécessaire pour tirer parti du contenu du CMS puisque GraphQL y a déjà accès, le plus difficile est de demander les requêtes correctes et efficaces pour l'obtenir.

L'autre option est l'intégration de fichiers plats. L'intégration de fichiers plats vous permet d'exporter les données normalement fournies via REST ou GraphQL sous forme de fichier .JSON, permettant ainsi au serveur de les mettre en cache et elles n'ont pas besoin d'être générées à chaque requête, ce qui les rend beaucoup plus rapides. L'utilisation de cette méthode générera automatiquement un nouvel ensemble de fichiers .JSON à chaque modification de la base de données. Il s'agit généralement d'une implémentation sur mesure et pas seulement d'un plug-in. Par conséquent, un développeur est nécessaire pour le configurer.

Les avantages et les inconvénients de WordPress Headless

Maintenant que vous savez ce qu'est WordPress Headless et en quoi il est différent d'une configuration WordPress conventionnel, voici les avantages et les inconvénients que vous devez connaître avant de prendre une décision.

Développement souple, de zéro.

Tout en utilisant WordPress comme système de gestion de contenu, le découplage de WordPress donne à vos développeurs la flexibilité de construire avec leurs technologies frontales préférées, telles que des frameworks comme Next.js . Au niveau de la surface, cela signifie beaucoup plus de liberté pour construire.

En surface, c'est fantastique. Mais cela signifie également que vous finissez par réinventer la roue pour les fonctionnalités de base, comme les plans de site et les permaliens, en vous assurant que les aperçus en direct du contenu des publications et des pages fonctionnent.

Et tu perds le la plupart Le flux de travail éditorial pour lequel WordPress est connu. La configuration de nouvelles pages devient souvent beaucoup plus compliquée et nécessite que les développeurs de secours déboguent lorsque les choses ne fonctionnent pas ils travaillent.

Créer des applications mobiles avec un backend WordPress

Un cas d'utilisation souvent négligé est que lorsque vous découplez WordPress, en l'utilisant exclusivement pour le backend, vous pouvez créer des applications mobiles.

Les applications sont complexes, bien plus que la création de sites Web à partir de zéro (c'est-à-dire avec ou sans WordPress), donc si vous finissez par emprunter cette voie, alors que le contenu sera basé sur l'API, une grande partie du reste dépendra des fonctionnalités de l'appareil. à l'aide de frameworks comme React Native. Voici une excellente comparaison des différentes façons de créer des applications mobiles à partir de Scott Bollinger d'AppPresser. L'un d'eux est, comme vous l'avez peut-être deviné, AppPresser, qui en est une excellente implémentation pour ceux qui veulent commencer tout de suite. Il est, bien sûr, propulsé par WordPress, utilisant des plugins WordPress, des thèmes et des API REST pour alimenter les applications mobiles iOS et Android natives/hybrides.

Commencer avec une solution comme celle-ci vous fera gagner des semaines, voire des mois de temps de développement et s'appuiera finalement sur les années d'expérience de leur équipe en interne, après des années de travail sur des projets clients et de test de la plate-forme en production pour la perfectionner.

De meilleures performances, avec des compromis.

Il existe trois façons principales de développer Headless

1. Côté client: tout est construit sur le navigateur en utilisant javascript avec le contenu chargé depuis le serveur lors de la connexion. Par exemple, l'utilisation de React en tant que moteur obtient les données via, par exemple, l'API REST. Lorsque la page est modifiée, il y a une demande de données supplémentaires à l'API et une nouvelle page est créée sur le client. Le plus souvent utilisé dans les applications à page unique (SPA)
2. Publication statique : tout est déjà compilé et exporté en HTML, CSS et JS sur le serveur. Puisqu'il ne sert que des fichiers statiques, ne générant pas dynamiquement la page, cela peut être stocké sur un serveur ou un CDN de très faible puissance. Cette méthode est très rapide. Cela se fait souvent avec quelque chose comme Next.js. Lorsque la page est éditée, une nouvelle page HTML est téléchargée depuis le serveur et affichée. Utilisé le plus souvent sur des sites qui ne changent pas souvent, tels que des sites de brochures ou de documentation.
3. Pages isomorphes : la première page Web accessible est Server Side Render (SSR) au format HTML, mais toutes les autres pages suivantes sont générées côté client si le client est en mesure de le faire. Si le client est incapable de générer la page, il la demandera au serveur. Le plus souvent utilisé sur les applications Web progressives (PWA), les sites hautement dynamiques ou ceux qui doivent servir des navigateurs Web plus anciens. Souvent un cadre tel que Svelte.kit.

Méthodes n. 1 et n. 3 peut utiliser des fichiers de données plats pour générer le HTML, ce qui les rend comparables à un site publié statique, mais l'utilisation de REST ou de GraphQL les ralentira légèrement car il faudra peut-être générer du contenu JSON à chaque requête.

Si des éléments tels que du contenu généré par l'utilisateur (formulaires ou commentaires) sont nécessaires, ces trois façons de travailler deviennent beaucoup plus complexes que dans WordPress standard. Prenons par exemple un formulaire de contact, le formulaire doit être construit pour fonctionner côté client et pouvoir envoyer ses informations via Javascript/AJAX au serveur, où elles sont ensuite vérifiées, désinfectées et placées dans la gestion du plug-in du formulaire de contact système. Comme il s'agit d'une manière complètement différente de travailler, il ne peut pas compter sur le créateur du plugin de formulaire de contact pour fournir ceci ou quoi que ce soit comme le pot de miel et d'autres protections anti-spam qui continueront de fonctionner. Vous aurez peut-être besoin d'un développeur pour créer un point de terminaison REST et le faire fonctionner selon vos besoins. Beaucoup plus complexe.

Les commentaires sont, en théorie, beaucoup plus simples car les points de terminaison REST existent déjà, mais vous aurez toujours besoin d'un développeur pour vous permettre de récupérer les commentaires approuvés et de les présenter dans une mise en page en fil de discussion, de télécharger de nouveaux commentaires dans le processus d'approbation et, bien sûr, de gérer le spam. . Lors du développement de Headless, il reste encore beaucoup à faire pour atteindre les mêmes objectifs qui ressortent des patterns avec WordPress ou qui sont possibles avec certains plugins.

La perception de un important sécurité? 

Il y a beaucoup de désinformation sur la sécurité de WordPress Headless. Effectuer une configuration de site statique avec un CDN est une bonne mesure préventive contre les attaques DDoS. Mais à terme, n'importe quel serveur peut être victime d'une attaque DDoS si vous ne mettez pas en place les systèmes nécessaires (ex : Cloudflare, etc.). Les configurations WordPress découplées fonctionnent avec WordPress installé sur un domaine ou sous-domaine séparé, avec le frontend sur le domaine standard.

Par exemple, si nous devions utiliser ce site Web, nous continuerions à utiliser ManageServer.it comme notre site accessible au public tout en ayant wp.Serveur géré.com mis en place comme un espace où notre équipe peut publier des articles de blog et gérer les parties du site qu'elle peut.

Et par exemple, utiliser une interface Next.js comme exemple signifierait la possibilité d'utiliser RSS (rendu côté serveur), où le HTML de la page est généré à chaque requête, ou SSG (génération statique), où le HTML de la page est généré au moment de la compilation. La génération statique permet de réutiliser le HTML pour chaque requête en lui permettant d'être mis en cache à partir d'un CDN.

Dans tous les cas, la couche de présentation communique toujours et demande du contenu à la couche de contenu exécutant WordPress. Cela signifie que la zone où vous hébergez le La couche de gestion de contenu pour la configuration sans tête de WordPress continuerait à exécuter WordPress.

Pour résumer, la réponse est sécurité est meilleur sur les sites Web Headless WordPress que les sites qui fonctionnent avec la configuration conventionnelle est que ça peut être. En termes simples, car il s'agit d'une configuration moins courante. Ce que nous entendons par là, c'est que la vraie raison pour laquelle certains essaient de peindre la perception qu'il y a des problèmes de sécurité avec les sites exécutant WordPress est que tant de sites exécutent WordPress et que les choses sont complètement flexibles ; donc évidemment, vous pouvez construire ou installer quelque chose qui n'est pas fiable, il en va de même si vous construisez avec headless et à peu près n'importe quelle autre pile.

Lorsque vous travaillez avec un fournisseur d'hébergement WordPress qui offre une expertise en matière de sécurité, d'évolutivité et de performances comme nous le faisons chez Managed Server, il est toujours possible de sécuriser vos sites sans sacrifier tout ce que vous pouvez faire avec WordPress, en ayant à passer par un développement coûteux. reconstruire à partir de zéro.

Autres inconvénients que vous pouvez rencontrer avec Headless

Les coûts de WordPress Headless

Nous l'avons déjà mentionné brièvement, mais en bref, Headless WordPress peut coûter assez cher. Pas seulement en termes de coûts de développement, mais peut-être plus important encore, de tempo. 

Votre groupe perd la capacité de se déplacer rapidement et d'itérer sans avoir à compter sur des ingénieurs internes (ou une agence).

Pour les équipes au rythme rapide qui ne voient pas leurs sites comme statiques, c'est un compromis qui n'en vaut finalement pas la peine. Nous avons vu de nos propres yeux comment des entreprises à 8 chiffres, qui ont clairement les ressources pour gérer WordPress Headless en interne, choisissent de passer à une configuration Headless et finissent par revenir parce que ce qu'elles ne pouvaient pas se permettre, c'était la perte de temps, la flexibilité d'agir rapidement. et finalement donner à plus d'une poignée de personnes de leur équipe le contrôle de travailler sur leur site.

Les bons développeurs qui savent ce qu'ils font peuvent être difficiles à trouver

WordPress Headless est encore une configuration relativement nouvelle. Ainsi, bien que trouver des développeurs JavaScript familiers avec JavaScript (et des frameworks comme React, Vue, Svelte, Gatsby) ne soit pas particulièrement difficile du tout - et peut-être même plus facile que de trouver de grands développeurs WordPress en ce moment, ceux qui le connaissent réellement. niveau frontal avec WordPress d'une manière conventionnelle qui adhère à toutes les meilleures pratiques a tendance à être plus difficile à trouver.

Pas toujours plus rapide que le cache périphérique avec Full Page Cache

Il existe des chemins plus faciles, et peut-être meilleurs, vers un site Web plus rapide.

La plupart des entreprises qui envisagent une architecture sans tête devraient corriger leur hébergement avant de prendre une décision beaucoup plus compliquée. Non seulement cela est beaucoup plus facile à faire, mais vous constaterez également rapidement des améliorations significatives sans un énorme investissement initial. Sans investir dans la reconstruction de votre site et renoncer à tous les avantages de votre installation WordPress dans son état actuel.

Quand devriez-vous éviter WordPress sans tête ?

En règle générale, WordPress Headless ne convient pas à la plupart des entreprises qui construisent avec WordPress. Bref, ceux qui :

• Vous voulez éviter de conserver deux couches distinctes (la couche de contenu et la couche de présentation).
• Je ne veux pas abandonner le flux de travail éditorial et de gestion de contenu pour lequel WordPress est connu.
• Donnez à leur équipe le contrôle et la flexibilité nécessaires pour travailler sans avoir à dépendre constamment de vos développeurs.
• Vous voulez économiser des ressources (temps et argent).
• Il n'y a pas de développeurs expérimentés disponibles pour faire les bons choix sur la façon dont le système est construit.
• Vous cherchez à embaucher des intérimaires ou à faire appel à une agence pour développer votre site en vue d'évolutions ultérieures ?

À qui s'adresse WordPress Headless ? 

Headless WordPress peut être une bonne option pour votre équipe si :

• Votre équipe de développement connaît bien la création de frameworks JavaScript, et trouver un développeur WordPress n'est pas une option (pour une raison quelconque). Mais souhaite également continuer à utiliser WordPress comme système de gestion de contenu, WordPress Headless peut être une bonne option.
• Votre équipe souhaite obtenir des résultats spécifiques, tels que la continuité entre la conception d'une plate-forme SaaS déjà construite, ce qui rendrait plus difficile leur reconstruction et leur maintenance dans WordPress. Dans ce cas, séparer les couches de contenu et de présentation peut être une bonne option.
• Vous êtes déterminé à ne pas construire dans les limites des thèmes WordPress et ne comptez pas spécifiquement sur les fonctionnalités supplémentaires offertes par les plugins.
• En tant qu'employeur, vous souhaitez continuellement former votre personnel technique avec les dernières compétences et savoir qu'en leur fournissant ces connaissances, ils sont plus susceptibles de rester avec vous plus longtemps.
• Votre objectif est d'effectuer des optimisations de n -ième degré sur toutes les parties de la pile.

Bilan après action : évaluer l'absence de tête comme solution

Certains veulent explorer Headless parce que c'est la nouvelle chose brillante avec laquelle peu d'autres travaillent. Non parce que c'est vraiment la meilleure solution pour un problème spécifique qui autrement ne serait pas réalisable. En tant que sous-produit, la plupart des sites qui adoptent l'approche sans tête entrent dans la catégorie d'ingénierie excessive sans le besoin. 

Il va sans dire qu'il existe également des implémentations et des scénarios WordPress Headless intéressants où cela peut être un excellent choix. Ceux où le choix est ce qui permet aux équipes de créer des sites Web incroyables qui conduisent au résultat qu'ils essaient d'atteindre.

Vous vous demandez toujours si WordPress Headless correspond à ce que votre équipe recherche ? Ne hésitez pas à réservez un appel avec nous et nous serons heureux de parler des problèmes que vous rencontrez et d'envisager la mise en œuvre de WordPress Headless à résoudre.

Ou, si ce guide a déjà répondu à toutes vos questions et que vous êtes prêt à essayer l'approche Managed Server :

Intéressé par un hébergement géré qui est empiriquement plus rapide ? Essayez notre approche de l'hébergement WordPress:

• Évolutivité : lors de tests de charge de travail d'utilisateurs réels, le serveur géré a fourni un temps de réponse moyen de 65 ms, 4,9 fois plus rapide que les meilleurs temps de réponse.
• Les temps de chargement globaux les plus rapides : Les temps de chargement moyens des pages de 1,26 seconde nous placent en tête de la liste des résultats mondiaux de WebPageTest.
• La vitesse de traitement la plus rapide : Les serveurs gérés offrent des vitesses de base de données jamais vues auparavant, traitant 2,44 fois plus de requêtes par seconde que la moyenne et exécutant PHP 2,6 fois plus rapidement que le deuxième meilleur !
• Sécurité et disponibilité parfaites : Avec une disponibilité de 100 % sur tous les moniteurs et une note A + sur notre implémentation SSL, vous pouvez être assuré que votre site est en ligne et sécurisé.