WordPress fără cap: ce este și ai nevoie de el?

La Servebolt, suntem mari susținători ai WordPress și a ecosistemului său. De asemenea, îl folosim pentru propriile noastre site-uri, deoarece considerăm că este cel mai bun sistem de gestionare a conținutului, așa cum statisticile continuă să arate an de an. Este open-source, versatil și simplu spus, este incredibil de ușor de înțeles de ce alimentează peste 40% din toate site-urile de pe internet.

Având în vedere cât de mare este ecosistemul și comunitatea de dezvoltatori care înconjoară WordPress, nu este surprinzător faptul că oamenii folosesc WordPress în moduri diferite. O astfel de abordare este utilizarea WordPress ca un CMS fără cap – pe scurt, denumit WordPress fără cap, care este în creștere în popularitate.

În acest ghid, vom detalia tot ce trebuie să știți despre WordPress fără cap, avantajele, dezavantajele și multe altele din experiența de primă mână a echipei noastre.

Ce este Headless WordPress?

Pentru a înțelege WordPress fără cap, trebuie să știți ce este WordPress monolitic. Monolithic , sau WordPress în forma sa tradițională, este WordPress așa cum îl cunoașteți. Este un sistem de management al conținutului pe care îl poți folosi pentru a gestiona tot conținutul de pe site-ul tău.

În general, WordPress are backend (sistemul de management al conținutului) și stratul de prezentare, care vă permite să vă proiectați site-ul. Cu toate acestea, site-urile WordPress fără cap sunt cele care se bazează pur și simplu pe WordPress ca sistem de gestionare a conținutului și folosesc o stivă diferită de front-end pentru a afișa conținutul.

Acest lucru permite o mai mare flexibilitate în ceea ce privește dezvoltarea. În esență, cu ajutorul API-ului REST, puteți utiliza WordPress pentru funcționalitatea sa de gestionare a conținutului, în timp ce îl asociați cu un frontend construit separat într-un cadru precum Vue.js sau React (pentru a numi doar câteva, există o gamă întreagă de alte cadre și instrumente frontend disponibile).

WordPress este considerată arhitectură CMS cuplată, deoarece toate instrumentele de editare front-end și funcționalitatea back-end de gestionare a conținutului (editare) sunt cuplate. Acest lucru permite echipelor de dezvoltatori, editori, copywriteri și altele să gestioneze atât stratul de prezentare, cât și conținutul. Spre deosebire de site-urile WordPress fără cap, care urmează o arhitectură decuplată, în care stratul de prezentare și conținutul sunt – după cum sugerează și numele – decuplate.

Integrare REST, GraphQL și Flat-File

O configurare CMS fără cap folosește API-uri și CDN-uri pentru a reda conținut. Și în acest moment, există trei opțiuni disponibile - API-ul REST, integrarea Flat-File și GraphQL.

WordPress folosește API-ul REST pentru a vă permite să conectați interfața la CMS. O API REST este pur și simplu o interfață de programare a aplicațiilor care urmează constrângerile arhitecturii REST, oferind o interfață uniformă care permite serverelor și clienților să transfere date între ele. REST permite dezvoltatorilor să expună și să utilizeze date specifice, dacă punctul final REST nu are datele direct disponibile, va avea nevoie de dezvoltare suplimentară.

O altă alternativă este GraphQL (QL este prescurtarea de la Query Language). GraphQL facilitează interogarea API-urilor cu câmpuri și relații specifice, la fel cum ați putea face cu o bază de date. Aceasta este o îmbunătățire semnificativă și există un plugin care face disponibil un API GraphQL pe WordPress . Acest lucru poate însemna că nu este nevoie de dezvoltare suplimentară pentru a exploata conținutul CMS, deoarece GraphQL are deja acces la acesta, partea mai complexă este să solicite interogările eficiente potrivite pentru a-l obține.

Cealaltă opțiune este integrarea fișierelor plat. Integrarea cu fișiere plate vă permite să exportați datele care sunt furnizate în mod normal prin REST sau GraphQL ca fișier .JSON, permițând astfel serverului să le memoreze în cache și nu trebuie să fie generate la fiecare solicitare, făcând-o mult mai rapidă. Utilizarea acestei metode va genera automat un nou set de fișiere .JSON cu fiecare modificare a bazei de date. Aceasta este în mod normal o implementare personalizată și nu doar un plugin. Prin urmare, este nevoie de un dezvoltator pentru a-l configura.

Avantajele și dezavantajele WordPress fără cap

Acum că știți ce este WordPress fără cap și cum este diferit de o configurare convențională WordPress, iată avantajele și dezavantajele pe care ar trebui să le cunoașteți înainte de a lua o decizie.

Dezvoltare flexibilă, În timp ce utilizați în continuare WordPress ca sistem de gestionare a conținutului, decuplarea WordPress oferă dezvoltatorilor dvs. flexibilitatea de a construi cu tehnologiile frontend alese – adică cadre precum Next.js . La nivel de suprafață, aceasta înseamnă mult mai multă libertate de construcție.

La suprafață, acest lucru este grozav. Dar înseamnă, de asemenea, că ajungi să reinventezi roata pentru funcționalitatea de bază, cum ar fi sitemap-urile și permalink-urile, asigurându-te că previzualizările live ale conținutului postării și paginii funcționează.

Și pierzi majoritatea fluxului de lucru editorial pentru care este cunoscut WordPress. Configurarea de noi pagini devine adesea mult mai implicată și necesită dezvoltatorilor aflați în așteptare să depaneze atunci când lucrurile nu funcționează doar .

Crearea de aplicații mobile cu un backend WordPress

Un caz de utilizare adesea trecut cu vederea este că atunci când decuplați WordPress, folosindu-l numai pentru backend, puteți crea aplicații mobile.

Aplicațiile sunt complexe, mult mai mult decât construirea de site-uri web de la zero (adică cu sau fără WordPress) – așa că, dacă ajungeți pe această cale, în timp ce conținutul va fi bazat pe API, o mare parte din restul se va baza pe caracteristicile dispozitivului nativ. cu ajutorul cadrelor precum React Native. Iată o comparație excelentă a diferitelor moduri de a crea aplicații mobile de la Scott Bollinger de la AppPresser. Unul dintre acestea este, după cum probabil ați ghicit, AppPresser, care este o implementare excelentă a acestui lucru pentru cei care doresc să înceapă de la cutie. Este – desigur – alimentat de WordPress, folosind pluginuri WordPress, teme și API-ul REST pentru a alimenta aplicațiile mobile iOS și Android native/hibride.

Începând cu o astfel de soluție, vă va economisi săptămâni, dacă nu luni, de timp de dezvoltare și, în cele din urmă, se bazează pe anii de experiență internă a echipei lor de la lucrul la proiectele clienților de ani de zile și testarea platformei în producție pentru a o perfecționa.

Performanță mai bună, cu compromisuri.

Există trei moduri principale prin care pot fi dezvoltate fără cap

1. Partea client : Totul este construit pe browser folosind javascript cu conținutul încărcat de pe server atunci când îl accesați. De exemplu, folosind React ca motor obține datele prin, de exemplu, API-ul REST. Când pagina este schimbată, există o solicitare pentru mai multe date către API și o nouă pagină este construită pe client. Cel mai des folosit în aplicații cu o singură pagină (SPA)
2. Publicat static : totul este deja construit și exportat ca HTML, CSS și JS pe server. Deoarece servește doar fișiere statice, nu generează pagina în mod dinamic, aceasta poate fi stocată pe un server sau CDN cu putere redusă. Această metodă este fulgerător. Acest lucru se face adesea cu ceva de genul Next.js. Când pagina este schimbată, o nouă pagină HTML este descărcată de pe server și afișată. Cel mai des folosit pe site-uri care nu se schimbă adesea, cum ar fi site-urile de broșuri sau documentația.
3. Pagini izomorfe : Prima pagină web accesată este Server Side Rendered (SSR) ca HTML, dar toate celelalte pagini ulterioare sunt generate pe partea clientului, dacă clientul este capabil. Dacă clientul nu poate genera pagina, o va cere de la server. Cel mai adesea folosit pe aplicații web progresive (PWA), site-uri foarte dinamice sau cele care trebuie să servească browsere web mai vechi. Adesea se folosește un cadru precum Svelte.kit pentru aceasta.

Metodele #1 și #3 ar putea folosi fișiere de date plate pentru a genera HTML, făcându-le comparabile cu un site publicat static, dar utilizarea REST sau GraphQL le va încetini puțin, deoarece poate fi necesar să genereze conținutul JSON la fiecare solicitare.

Dacă sunt necesare lucruri precum conținutul generat de utilizatori (formulare sau comentarii), aceste trei moduri de lucru devin mult mai complexe decât WordPress standard.

Să luăm ca exemplu un formular de contact, formularul trebuie să fie construit pentru a funcționa pe partea clientului și să poată trimite informațiile sale prin Javascript/AJAX înapoi la server, unde este apoi verificat, igienizat și inserat în contact. sistem de gestionare a pluginurilor de formulare. Deoarece acesta este un mod total diferit de lucru, nu se poate baza pe producătorul de pluginuri pentru formulare de contact pentru a oferi așa ceva, cum ar fi vasele de miere și alte protecție împotriva spamului, vor continua să funcționeze. Ar putea avea nevoie de un dezvoltator pentru a crea un punct final REST și pentru a face totul să funcționeze după cum este necesar. Mult mai complex.

Comentariile sunt, teoretic, mult mai ușoare, deoarece punctele finale REST există deja, dar totuși, va fi nevoie ca un dezvoltator să facă posibilă preluarea comentariilor aprobate și prezentarea lor într-un aspect cu fire de execuție, încărcarea de noi comentarii în procesul de aprobare. , și bineînțeles să se ocupe de spam.

Când se dezvoltă într-un mod fără cap, sunt mai multe de făcut pentru a atinge aceleași obiective care ies din cutie cu WordPress sau sunt posibile cu câteva plugin-uri.

Percepția de securitate Există o mulțime de informații greșite în jurul securității WordPress fără cap. Rularea unei configurații statice de site cu un CDN este o măsură bună de prevenire împotriva atacurilor DDoS. Dar, în cele din urmă, orice server poate fi victima unui atac DDoS dacă nu puneți în aplicare sistemele necesare (adică Cloudflare, etc). Configurațiile WordPress decuplate funcționează cu WordPress instalat pe un domeniu sau subdomeniu separat, cu interfața pe domeniul standard.

De exemplu, dacă ar fi să folosim acest site web, am continua să folosim servebolt.com ca site-ul nostru accesibil public, în timp ce am configurat Și, de exemplu, folosirea unui frontend Next.js ca exemplu ar însemna că aveți de ales să utilizați fie SSR (redare pe server), în care pagina HTML este generată la fiecare solicitare, fie SSG (generare statică), în care pagina HTML este generat în timpul construirii. Generarea statică permite reutilizarea HTML-ului pentru fiecare cerere, permițându-i să fie stocat în cache de către un CDN.

În ambele cazuri, stratul de prezentare încă comunică și solicită conținut de la stratul de conținut care rulează WordPress. Aceasta înseamnă că zona în care găzduiești stratul de gestionare a conținutului pentru configurarea WordPress fără cap ar rula în continuare WordPress.

Pentru a rezuma acest lucru, răspunsul dacă securitatea este mai bună pe site-urile WordPress fără cap față de site-urile care rulează în configurația convențională este că poate fi. Pur și simplu, pentru că este o configurație mai puțin obișnuită. Ceea ce vrem să spunem prin aceasta este că adevăratul motiv pentru care unii încearcă să creeze percepția că există probleme de securitate cu site-urile care rulează WordPress este că atât de multe site-uri rulează WordPress și lucrurile sunt complet flexibile, așa că, desigur, puteți construi sau instala ceva care nu este de încredere, același lucru este adevărat dacă construiți cu headless și practic orice alt stivă.

Când lucrați cu un furnizor de găzduire WordPress care aduce competență în securitate, scalare și performanță așa cum o facem la Servebolt , este foarte posibil să vă păstrați site-urile în siguranță fără a sacrifica tot ceea ce puteți face cu WordPress - trebuie să suportați o dezvoltare costisitoare costurile de reconstrucție de la zero.

Mai multe dezavantaje pe care probabil să le întâlnești cu fără cap

Costurile WordPress fără cap

Am atins deja pe scurt acest lucru, dar pe scurt, WordPress fără cap poate deveni destul de scump. Nu doar în ceea ce privește costul de dezvoltare, dar poate și mai important, timpul.

Echipa dvs. își pierde capacitatea de a se mișca rapid și de a repeta fără a fi nevoită să se bazeze pe ingineri interni (sau o agenție).

Pentru echipele cu ritm rapid care nu își văd site-urile ca fiind statice, acesta este un compromis care nu ajunge să merite. Am văzut direct cum companiile cu 8 cifre – care au în mod clar resursele pentru a gestiona WordPress fără cap intern – fac alegerea de a trece la o configurație fără cap și, în cele din urmă, să se întoarcă, deoarece ceea ce nu și-au putut permite să suporte era pierdere de timp, flexibilitate de a se deplasa rapid și, în cele din urmă, oferă mai mult decât doar o mână de oameni din echipa lor controlul pentru a lucra pe site-ul lor.

Dezvoltatorii buni care știu ce fac pot fi greu de găsit

WordPress fără cap este încă o configurație relativ nouă. Deci, deși găsirea dezvoltatorilor JavaScript familiarizați cu JavaScript (și cadre precum React, Vue, Svelte, Gatsby) nu este deloc dificilă - și poate chiar mai ușor decât găsirea de dezvoltatori WordPress grozavi în acest moment, cei care sunt de fapt familiarizați cu integrarea stratului frontend cu WordPress într-un mod convențional care respectă toate cele mai bune practici tind să fie mai dificil de găsit.

Nu întotdeauna mai rapid decât stocarea în cache pe marginea întregii pagini

Există căi mai ușoare – și posibil mai bune – către un site web mai rapid.

Majoritatea companiilor care iau în considerare arhitectura fără cap ar trebui să își repare mai întâi găzduirea înainte de a lua o decizie semnificativ mai implicată. Nu numai că este mult mai ușor să faceți acest lucru, dar veți vedea rapid îmbunătățiri semnificative fără o investiție uriașă în avans. Fără să investești în reconstruirea site-ului tău și să schimbi toate beneficiile instalării tale WordPress în starea sa actuală.

Când ar trebui să evitați WordPress fără cap?

Ca regulă generală, WordPress fără cap nu este potrivit pentru majoritatea companiilor care construiesc cu WordPress. Pe scurt, cei care:

• Doriți să evitați menținerea a două straturi separate (nivelul de conținut și stratul de prezentare).
• Nu doriți să renunțați la fluxul de lucru editorial și de management al conținutului pentru care este cunoscut WordPress.
• Permiteți echipei lor să aibă control și flexibilitate pentru a lucra fără a fi nevoit să se bazeze constant pe dezvoltatorii dvs.
• Doriți să economisiți resurse (timp și bani).
• Nu aveți la dispoziție dezvoltatori experimentați care să facă alegerile corecte cu privire la modul în care este realizat sistemul.
• Căutați să angajați lucrători temporari sau să solicitați unei agenții să vă dezvolte site-ul cu ochii pe evoluțiile viitoare ulterioare?

Pentru cine este bun WordPress fără cap?

WordPress fără cap poate fi o opțiune bună pentru echipa ta dacă:

• Echipa ta de dezvoltare este calificată în construirea cu framework-uri JavaScript și găsirea unui dezvoltator WordPress nu este o opțiune (din orice motiv ar fi acesta). Dar vrea să continue să folosească WordPress ca sistem de gestionare a conținutului, WordPress fără cap poate fi o opțiune bună.
• Echipa dvs. dorește să realizeze lucruri specifice, cum ar fi continuitatea între designul unei platforme SaaS care este deja construită, ceea ce ar face ca reconstrucția acestora și menținerea lor în WordPress să fie mai eficientă. În acest caz, separarea conținutului și stratul de prezentare poate fi o opțiune bună.
• Sunteți hotărât să nu construiți în limitele temelor WordPress și să nu vă bazați în mod special pe nicio funcționalitate suplimentară oferită de pluginuri.
• În calitate de angajator, doriți să vă pregătiți în mod continuu personalul tehnic cu cele mai noi abilități și știți că, oferindu-le aceste cunoștințe, este mai probabil că vor rămâne cu dvs. mai mult timp.
• Scopul dvs. este să efectuați optimizări de gradul n pe toate părțile stivei.

Exemple de site-uri web create cu WordPress fără cap

Healthline

TechCrunch

Frontitate

Backlinko

Rudis

Raport după acțiune – Evaluarea Headless ca soluție

Unii vor să exploreze fără cap pentru că este lucrul nou strălucitor cu care puțini alții lucrează. Nu pentru că ar fi cu adevărat cea mai bună soluție la o problemă specifică care altfel nu ar fi realizabilă. Ca produs secundar, majoritatea site-urilor care adoptă abordarea fără cap intră în categoria suprainginerării fără a fi nevoie.

Este de la sine înțeles că există și implementări interesante ale WordPress fără cap și scenarii în care poate fi o alegere excelentă. Cele în care alegerea este ceea ce permite echipelor să construiască site-uri web incredibile care conduc la rezultatul pe care doresc să-l obțină.

Încă te întrebi dacă WordPress fără cap se aliniază cu ceea ce caută echipa ta? Nu ezitați să rezervați un apel cu noi și vom fi bucuroși să discutăm despre problemele pe care le întâmpinați și vă gândiți să implementați WordPress fără cap pentru a le rezolva.

Sau, dacă acest ghid ți-a răspuns deja la toate întrebările și ești gata să încerci abordarea Servebolt:

Vă interesează găzduirea gestionată care este empiric mai rapidă? Încercați abordarea noastră de găzduire WordPress :

• Scalabilitate: În testele de sarcină de lucru cu utilizatorii reale, Servebolt a furnizat timpi medii de răspuns de 65 ms, timpi de răspuns de 4,9 ori mai rapid decât al doilea cel mai bun.
• Cei mai rapidi timpi de încărcare la nivel global: timpii medii de încărcare a paginii de 1,26 secunde ne plasează în fruntea listei de rezultate globale WebPageTest.
• Cea mai rapidă viteză de calcul: serverele Servebolt oferă viteze de bază de date nemaivăzute până acum, procesând de 2,44 ori mai multe interogări pe secundă decât media și rulând PHP de 2,6 ori mai rapid decât cel mai bun!
• Securitate și timp de funcționare perfecte: cu un timp de funcționare de 100% pe toate monitoarele și un rating A+ pentru implementarea noastră SSL, puteți fi siguri că site-ul dvs. este online și securizat.