WordPress sans tête : qu'est-ce que c'est et en avez-vous besoin ?

Chez Servebolt, nous sommes de grands défenseurs de WordPress et de son écosystème. Nous l'utilisons également pour nos propres sites car nous pensons vraiment que c'est le meilleur système de gestion de contenu, comme les statistiques continuent de le montrer année après année. Il est open-source, polyvalent et en termes simples, 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 qui entourent 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 CMS sans tête - en bref, appelé WordPress sans tête, qui gagne en popularité.

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

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

Pour comprendre WordPress sans tête, vous devez savoir ce qu'est WordPress monolithique. Monolithic , ou WordPress dans sa forme traditionnelle, est WordPress tel que vous le connaissez. C'est un système de gestion de contenu que vous pouvez utiliser pour gérer tout le contenu de votre site.

Généralement, 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 WordPress sans tête sont ceux qui s'appuient simplement sur WordPress en tant que 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. Essentiellement, avec l'aide de l'API REST, vous pouvez utiliser WordPress pour sa fonctionnalité de gestion de contenu tout en l'associant à une interface construite séparément dans un framework comme Vue.js ou React (pour n'en nommer que quelques-uns, il existe toute une gamme 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, éditeurs, rédacteurs, etc. de gérer à la fois la couche de présentation et le contenu. Contrairement aux sites Web WordPress sans tête qui suivent une architecture découplée dans laquelle la couche de présentation et le contenu sont - comme son nom l'indique - découplés.

Intégration REST, GraphQL et fichier plat

Une configuration CMS sans tête utilise des API et des CDN pour restituer le contenu. Et pour le moment, trois options sont disponibles : 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, il nécessitera un développement supplémentaire.

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 plugin qui rend une API GraphQL disponible sur WordPress . Cela peut signifier qu'un développement supplémentaire n'est pas nécessaire pour exploiter le contenu du CMS car GraphQL y a déjà accès, la partie la plus complexe consiste à demander les bonnes requêtes 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 de ne pas avoir à les générer à 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 apportée à la base de données. Il s'agit normalement d'une implémentation sur mesure et pas seulement d'un plugin. Par conséquent, un développeur est nécessaire pour le configurer.

Les avantages et les inconvénients de WordPress sans tête

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

Développement flexible, 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 les technologies frontales de leur choix, c'est-à-dire des frameworks comme Next.js . Au niveau de la surface, cela signifie beaucoup plus de liberté pour construire.

En surface, c'est super. 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, garantissant que les aperçus en direct du contenu des publications et des pages fonctionnent.

Et vous perdez la majorité du flux de travail éditorial pour lequel WordPress est connu. La configuration de nouvelles pages devient souvent beaucoup plus compliquée et nécessite des développeurs en attente pour déboguer lorsque les choses ne fonctionnent pas simplement .

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 uniquement 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 suivre cette voie, alors que le contenu sera piloté par l'API, une grande partie du reste s'appuiera sur les fonctionnalités natives 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 de Scott Bollinger d'AppPresser. L'un d'entre eux est, comme vous l'avez peut-être deviné, AppPresser, qui en est une excellente implémentation pour ceux qui veulent se lancer. Il est - bien sûr - alimenté par WordPress, utilisant des plugins WordPress, des thèmes et l'API REST pour alimenter les applications mobiles natives/hybrides iOS et Android.

Commencer avec une solution comme celle-ci vous fera gagner des semaines, voire des mois de temps de développement et est finalement basé sur les années d'expérience de leur équipe en interne, travaillant sur des projets clients pendant des années et testant la plate-forme en production pour l'affiner.

De meilleures performances, avec des compromis.

Il existe trois façons principales de développer le headless

1. Côté client : Tout est construit sur le navigateur en utilisant javascript avec le contenu chargé depuis le serveur lors de l'accès. Par exemple, l'utilisation de React comme moteur obtient les données via, par exemple, l'API REST. Lorsque la page est modifiée, une demande de données supplémentaires est envoyée à 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à construit et exporté au format HTML, CSS et JS sur le serveur. Parce qu'il ne sert que des fichiers statiques, sans générer dynamiquement la page, cela peut être stocké sur un serveur ou un CDN à très faible puissance. Cette méthode est rapide comme l'éclair. Cela se fait souvent avec quelque chose comme Next.js. Lorsque la page est modifiée, une nouvelle page HTML est téléchargée depuis le serveur et affichée. Le plus souvent utilisé sur des sites qui ne changent pas souvent, comme les sites de brochures ou de documentation.
3. Pages isomorphes : la première page Web accessible est rendue côté serveur (SSR) en HTML, mais toutes les autres pages suivantes sont générées côté client si le client en est capable. Si le client ne peut pas 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 framework tel que Svelte.kit est utilisé pour cela.

Les méthodes #1 et #3 pourraient utiliser des fichiers de données plats pour générer le HTML, les rendant comparables à un site publié statique, mais l'utilisation de REST ou GraphQL les ralentira un peu car il faudra peut-être générer le contenu JSON à chaque requête.

Si des choses comme du contenu généré par l'utilisateur sont nécessaires (formulaires ou commentaires), ces trois façons de travailler deviennent beaucoup plus complexes que WordPress standard.

Prenons un formulaire de contact comme exemple, le formulaire doit être conçu pour fonctionner côté client et pouvoir renvoyer ses informations via Javascript/AJAX au serveur, où elles sont ensuite vérifiées, désinfectées et insérées dans le contact système de gestion de plugin de formulaire. Parce qu'il s'agit d'une manière totalement différente de travailler, il ne peut pas compter sur le fabricant de plugins de formulaire de contact pour fournir ceci ou que des choses comme les pots de miel et autres protections anti-spam continueront de fonctionner. Il peut avoir besoin d'un développeur pour créer un point de terminaison REST et le faire fonctionner selon les besoins. Beaucoup plus complexe.

Les commentaires sont, en théorie, beaucoup plus faciles car les points de terminaison REST existent déjà, mais il faudra quand même qu'un développeur permette de récupérer les commentaires approuvés et de les présenter dans une mise en page filetée, de télécharger de nouveaux commentaires dans le processus d'approbation. , et bien sûr gérer les spams.

Lors du développement sans tête, il y a plus à faire pour atteindre les mêmes objectifs qui sortent de la boîte avec WordPress ou qui sont possibles avec quelques plugins.

La perception d' une sécurité Il y a beaucoup de désinformation autour de la sécurité de WordPress sans tête. L'exécution d'une configuration de site statique avec un CDN est une bonne mesure préventive contre les attaques DDoS. Mais finalement, n'importe quel serveur peut être victime d'une attaque DDoS si vous ne mettez pas en place les systèmes nécessaires (c'est-à-dire 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 servebolt.com comme site accessible au public tout en ayant configuré Et par exemple, utiliser une interface Next.js comme exemple signifierait que vous avez le choix d'utiliser soit SSR (rendu côté serveur), où la page HTML est générée à chaque requête, soit SSG (génération statique), où la page HTML est généré au moment de la construction. La génération statique permet de réutiliser le HTML pour chaque requête lui permettant d'être mis en cache par un CDN.

Dans les deux cas, la couche de présentation communique toujours avec et demande du contenu à la couche de contenu qui exécute WordPress. Cela signifie que la zone dans laquelle vous hébergez la couche de gestion de contenu pour votre configuration WordPress sans tête exécutera toujours WordPress.

Pour résumer, la réponse à la question de savoir si la sécurité est meilleure sur les sites Web WordPress sans tête par rapport aux sites fonctionnant sur la configuration conventionnelle est qu'elle peut l'ê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 les choses sont entièrement flexibles, donc bien sûr, vous pouvez créer ou installer quelque chose qui n'est pas fiable, il en va de même si vous construisez avec headless et pratiquement n'importe quelle autre pile.

Lorsque vous travaillez avec un fournisseur d'hébergement WordPress qui apporte des compétences en matière de sécurité, de mise à l'échelle et de performances comme nous le faisons chez Servebolt , il est tout à fait possible de garder vos sites sécurisés sans sacrifier tout ce que vous pouvez faire avec WordPress - avoir à supporter un développement coûteux coûts pour reconstruire à partir de zéro.

Plus d'inconvénients que vous êtes susceptible de rencontrer avec sans tête

Les coûts de WordPress sans tête

Nous en avons déjà brièvement parlé, mais en bref, WordPress sans tête peut coûter assez cher. Pas seulement en termes de coût de développement, mais peut-être plus important encore, de temps.

Votre équipe perd la capacité d'agir rapidement et d'itérer sans avoir à s'appuyer sur des ingénieurs en interne (ou sur une agence).

Pour les équipes au rythme rapide qui ne considèrent pas leurs sites comme statiques, il s'agit d'un compromis qui n'en vaut pas la peine. Nous avons vu de première main comment des entreprises à 8 chiffres - qui ont clairement les ressources nécessaires pour gérer WordPress sans tête en interne - font le choix de passer à une configuration sans tête et finalement de revenir en arrière parce que ce qu'elles ne pouvaient pas se permettre de supporter était le perte de temps, flexibilité pour se déplacer rapidement et finalement donner à plus qu'une poignée de personnes dans leur équipe le contrôle pour travailler sur leur site.

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

Headless WordPress 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 en aucun cas particulièrement difficile - et peut-être même plus facile que de trouver de grands développeurs WordPress en ce moment, ceux qui sont réellement familiarisés avec l'intégration de la couche frontale 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 la mise en cache de bord pleine page

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 d'abord réparer leur hébergement avant de prendre une décision beaucoup plus complexe. Non seulement c'est beaucoup plus facile à faire, mais vous verrez également rapidement des améliorations significatives sans un énorme investissement initial. Sans investir dans la reconstruction de votre site et échanger 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 sans tête ne convient pas à la plupart des entreprises qui construisent avec WordPress. Bref, ceux qui :

• Souhaitent éviter de maintenir deux couches distinctes (la couche de contenu et la couche de présentation).
• Vous ne voulez pas abandonner le flux de travail éditorial et de gestion de contenu pour lequel WordPress est connu.
• Laissez leur équipe avoir le contrôle et la flexibilité de travailler sans devoir constamment compter sur vos développeurs.
• Vous voulez économiser des ressources (temps et argent).
• Ne pas avoir de développeurs expérimentés disponibles pour faire les bons choix sur la façon dont le système est fait.
• Vous cherchez à embaucher des intérimaires ou faire développer votre site par une agence en vue d'évolutions futures ?

À qui sert WordPress sans tête ?

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

• Votre équipe de développement est compétente pour construire avec des frameworks JavaScript, et trouver un développeur WordPress n'est pas une option (pour quelque raison que ce soit). Mais souhaite également continuer à utiliser WordPress comme système de gestion de contenu, WordPress sans tête peut être une bonne option.
• Votre équipe souhaite réaliser des choses spécifiques, comme la continuité entre la conception d'une plate-forme SaaS qui est déjà construite, ce qui rendrait plus de travail pour les reconstruire et les maintenir 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 former en permanence votre personnel technique avec les dernières compétences et savoir qu'en leur donnant ces connaissances, ils resteront probablement plus longtemps avec vous.
• Votre objectif est d'effectuer des optimisations au nième degré sur toutes les parties de la pile.

Exemples de sites Web construits avec WordPress sans tête

Ligne Santé

Tech Crunch

Frontité

Lien de retour

Roudis

Rapport après action - Évaluation du sans tête comme solution

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

Il va sans dire qu'il existe également des implémentations passionnantes de WordPress sans tête et des scénarios dans lesquels 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 cherchent à atteindre.

Vous vous demandez toujours si WordPress sans tête correspond à ce que votre équipe recherche ? N'hésitez pas à réserver un appel avec nous et nous serions heureux de discuter des problèmes que vous rencontrez et envisageons de mettre en œuvre WordPress sans tête pour les résoudre.

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

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

• Évolutivité : dans les tests de charge de travail des utilisateurs réels, Servebolt a fourni des temps de réponse moyens de 65 ms, soit des temps de réponse 4,9 fois plus rapides que le deuxième meilleur.
• Les temps de chargement mondiaux 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 calcul la plus rapide : les serveurs Servebolt offrent des vitesses de base de données sans précédent, traitant 2,44 fois plus de requêtes par seconde que la moyenne et exécutant PHP 2,6 fois plus vite 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é.