3 novembre 2022

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

SĂ©parez le backend et le frontend WordPress via l'approche Headless "headless".

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 sans tĂȘte

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Ă©.

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modÚle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

Retour en haut de page