Cum Smashing Magazine gestionează conținutul: migrarea de la WordPress la JAMstack

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la Netlify, o platformă all-in-one pentru automatizarea proiectelor web moderne. Mulțumesc!

De fiecare dată când dezvoltatorii vorbesc despre WordPress, cota lor de piață se schimbă. „ 20% din toate site-urile sunt pe WordPress! ” “ 40% din toate site-urile sunt pe WordPress! ” Oricare ar fi procentul, mesajul este același: în ceea ce privește adoptarea, WordPress este MASIV.

Deci, de ce, cu acest tip de adoptare, un site care utilizează WordPress ar lua în considerare trecerea la JAMstack? În această serie de articole din două părți, vom acoperi cum arată o migrare WordPress reală, folosind un studiu de caz al site-ului pe care îl citiți chiar acum.

Vom vorbi despre câștiguri și pierderi, despre lucrurile pe care am vrea să le știm mai devreme și despre ce am fost surprinși. Și apoi vom continua cu o demonstrație tehnică a unei posibile căi de migrare - nu complet din WordPress - ci cum puteți servi WordPress decuplat, astfel încât să puteți avea tot ce este mai bun din ambele lumi: o implementare JAMstack a WordPress care vă oferă toate puterea tabloului de bord și funcționalitatea lor, cu performanțe și securitate mai bune.

Să pătrundem!

De ce?

În 2015, co-fondatorul Netlify Mathias Biilmann și fondatorul Smashing Vitaly Friedman au vorbit despre magazin. Pe măsură ce arhitectura JAMstack a început să facă tururi, Smashing a devenit mai interesat de ideea stivei. Vitaly și Markus (fostul director general la Smashing) l-au întrebat pe Matt ce s-ar întâmpla dacă Smashing ar migra de la site-ul lor tradițional WordPress/LAMPstack la o arhitectură JAMstack.

Ca experiment, Matt a răzuit tot codul HTML din Smashing și l-a găzduit pe Netlify, livrând conținutul static dintr-un CDN. Rezultatele au fost convingătoare - versiunea statică este de peste șase ori mai rapidă în medie!

Acest tip de arhitectură funcționează atât de bine, în parte, deoarece paginile nu sunt compilate la cerere pe măsură ce le vizitați. Deoarece difuzați conținut preconstruit direct dintr-o rețea de difuzare a conținutului , site-ul este deja „acolo” și gata pentru utilizator.

Deoarece serviți prin CDN, puteți distribui conținutul pe tot globul, mai aproape de potențialii vizitatori. Nu există un punct central de origine, ceea ce este vital în cazul oricărei publicații online care dorește să fie rapidă pentru toți cititorii săi.

Așa că scena a fost pregătită. Smashing Magazine a migrat la JAMstack - în special la Netlify ca platformă. În cei 10 ani de funcționare, Smashing a crescut de la o mică publicație online la un blog WordPress masiv, vânzând lucruri precum cărți, bilete la conferințe și ateliere.

Au fost câteva bucăți de pe acest site:

• Blog WordPress
• Panou de locuri de muncă pentru șine
• Magazin Shopify
• Un alt CMS pentru site-ul conferinței

Când Netlify a început migrarea, site-ul suferea unele probleme de performanță, împovărați de 20.000 de comentarii și mii de articole. Smashing a fost, de asemenea, interesat de autentificare ca parte a unui nou plan de abonament, precum și de o reproiectare pentru un aspect mai modern.

Fiabilitate

Smashing realizează în mod regulat ceea ce visează alte platforme: articole distribuite pe scară largă printr-o comunitate enormă. Cu toate acestea, când a fost atins un punct de vârf al traficului pentru o postare, Smashing a avut în mod regulat probleme cu întreruperile. Pentru a atenua acest lucru, utilizarea intensivă a pluginurilor WordPress a fost introdusă în stiva lor, dar ei încă s-au luptat să păstreze valori bune de funcționare.

Mutarea la Netlify a permis echipei Smashing să evite să primească erori de conexiune la baza de date și să nu-și facă griji cu privire la timpul de nefuncționare chiar și atunci când un articol a înregistrat o cantitate mare de trafic. De ce? Pentru că atunci când se difuzează fără un server, conținutul preconstruit nu trebuie să fie generat și difuzat - acesta există deja, gata pentru a fi vizualizat. Nimic nu este solicitat la fața locului, cu excepția întregii pagini statice.

Servirea prin CDN a permis, de asemenea, Smashing-ului să doarmă puțin mai ușor în ceea ce privește securitatea. wp-login.php a fost mult timp o sursă de găuri de securitate și vectori de atac. Conținutul preconstruit nu poate fi accesat în același mod, iar găurile de securitate nu sunt la fel de omniprezente.

Invalidarea memoriei cache

Smashing a parcurs fiecare plugin de cache WordPress, cu rezultate variate și multe probleme. Vitaly Friedman din Smashing menționează,

„Principalele probleme pe care le-am avut au fost legate de „Eroare la stabilirea conexiunii la baza de date”, pe care o continuăm să o avem o dată la două săptămâni și am încercat literalmente fiecare plugin de cache WordPress de acolo. Performanța a fost destul de OK (în general), dar am căutat să o îmbunătățim în continuare. În plus, am vrut să lansăm Membership și să conectăm toate ofertele diferite - conferințe, posturi de muncă, articole, cărți, cărți electronice - cu o singură platformă și a fost remarcabil de dificil de realizat cu WordPress în joc.”

Mutarea la Netlify a permis echipei Smashing să vadă invalidarea instantanee a memoriei cache, oferind, de asemenea, conținut în cache și performant, fără costuri suplimentare.

Când implementați un site, fișierele HTML sunt găzduite pe CDN-ul Netlify. Este optimizat pentru o rată ridicată de accesare a cache-ului și timp rapid până la primul octet, putând în același timp să invalideze instantaneu toate fișierele HTML care s-au modificat. Netlify amprentează, de asemenea, toate linkurile către elemente precum fișiere CSS, imagini, fonturi sau fișiere JS și oferă Smashing cu anteturi de cache care le memorează pentru totdeauna. Amprentarea garantează că acestea sunt unice și că, dacă actualizați o versiune nouă, versiunea mai nouă este difuzată în schimb.

Fluxul de lucru

Privind configurația existentă, un motiv important pentru migrare a fost pur și simplu unificarea proprietăților existente. A trebuit să schimbe contextul între toate aceste stive și setări tehnologice diferite a devenit o problemă grea de întreținere care a pus sarcina inginerilor.

Când anterior infrastructura lor era împărțită între atât de multe sisteme diferite, acest proces de migrare a unificat, de asemenea, totul , păstrând site-ul principal, site-ul conferinței, abonamentele și secțiunea de comerț electronic, toate lucrând împreună în loc să fie menținute separat cu stive diferite. Acest lucru a ajutat la menținerea costurilor de dezvoltare scăzute și la experiența dezvoltatorului de lucru pe toate proprietățile în mod constant.

Piesa de migrare WordPress s-a dovedit a fi cea mai mare și mai delicată. Netlify a încercat să exporte datele de la exportatorul WP, doar pentru a constata că conținutul avea încorporare care trebuiau păstrate sau, uneori, erau modificate de pluginuri. Pentru a menține paritatea cu ceea ce era pe site, au fost scrise o serie de scrapers, defalcate pe articole, active, comentarii și pagina de pornire.

Odată ce a fost scris și transformat, a fost încărcat într-un nou depozit în GitHub, iar Netlify CMS a fost folosit în schimb. Ceea ce face Netlify CMS unic este faptul că este ușor și integrează editorii de conținut într-un flux de lucru Git - ceea ce înseamnă că va trage și va servi literalmente fișiere de reducere dintr-un repository git în loc de o bază de date. În plus, Netlify CMS este independent de platformă și funcționează cu (aproape) toate generatoarele de site-uri statice și site-urile stocate în GitHub.

La acel moment, Sara Soueidan lucra pentru Smashing ca dezvoltator front-end independent la reproiectarea lor. Ea a creat o bibliotecă de componente pentru a construi arhitectura front-end și a remarcat cât de mult mai simplu era să lucrezi, deoarece lucra direct în git, chiar și atunci când lucra cu CMS.

„Tot ceea ce am trimis în depozit este aplicat direct bibliotecii de modele, ceea ce înseamnă că nu trebuie să menții două seturi diferite de componente... acest tip de continuitate a fost grozav! Tot ce trebuie să fac este să scriu HTML, CSS și JavaScript și să împing în repo și totul funcționează ca magic. Fluxul de lucru a fost fantastic.”

Toate acestea spuse, Netlify CMS poate fi uneori prea ușor pentru un caz de utilizare atât de mare și de scară. Smashing are în mod regulat autori invitați și o redacție completă. Unele dintre funcțiile bogate oferite de WordPress sunt cu adevărat utile pentru aceste tipuri de medii extrem de colaborative.

De aceea, în următorul tutorial, vă vom ghida printr-un model fără cap , în care puteți în continuare să profitați de beneficiile tabloului de bord WordPress pentru creatorii de conținut, dar să utilizați WordPress prin API și ca dezvoltarea să se bazeze pe un flux de lucru centrat pe git atât de ușor. pentru a menține și dezvoltatorii. Rămâneți aproape!

Alegeri cadru

În prototipul inițial pe care l-a creat Matt Biilmann, el a scris totul în Preact minimal, împreună cu Hugo, deoarece era foarte concentrat pe performanță. A folosit doar recuzită și a păstrat totul foarte ușor. Pe măsură ce a transmis proiectul pentru a fi întreținut de dezvoltatorul Smashing, Ilya Pukhalski, a descoperit că Preact îi lipseau unele caracteristici care le lipseau pentru a accesa ecosistemul React. În cele din urmă, beneficiile Redux și ale altor biblioteci au depășit costurile.

Reflectând acum, Matt spune că ar fi folosit Vue, care nu avea o cotă de piață la acea vreme (jur că nu l-am îndemnat să spună asta). Am pus întrebarea evidentă: de ce nu Svelte? Pe măsură ce oamenii care se gândesc la performanță tind să ajungă la acea bibliotecă. El a menționat că Svelte nu are încă ecosistemul pe care Vue îl are.

Când Matt se gândește dacă l-ar fi folosit sau nu în continuare pe Hugo, el spune că îl iubește pe Hugo, dar ceea ce i s-a părut dificil pentru acest proiect în special a fost că nu avea suficient un sistem de pluginuri - creând reclame banner și lucruri de că natura nu era suficient de programabilă cu Hugo și trebuia să injecteze scripturi pentru a o realiza. Aceste scripturi au avut tendința de a încetini procesul de construire. Acestea fiind spuse, încă îl folosim pe Hugo pentru propriul nostru site la netlify.com și îl iubim - această avertizare este extrem de specială pentru nevoile site-ului Smashing în special.

Dacă ar putea să o facă din nou, ar putea alege fie Eleventy, care are capabilități bogate în ceea ce privește crearea de pluginuri și alte scripturi extensibile. Sau, dacă ar fi folosit Vue, Nuxt i-ar fi oferit câteva capabilități frumoase de plugin, permițând în același timp să fie o alegere bună pentru acel cadru, oferind randare pe server, rutare și generare statică.

Construirea de Situri Mari

A apărut o problemă în lucrul cu un site la fel de mare precum Smashing și poate că vă puteți da seama deja ce este, tocmai am atins-o. Este adevărat că, cu orice site mare de pagini preconstruite difuzate pe un CDN, performanța este încă grozavă, deoarece nu construim nimic din mers pentru utilizatori.

Dar acest beneficiu se poate întâmpla numai dacă site-ul este pre-construit, iar acest proces poate consuma mult timp. În timp ce site-urile mai tradiționale vor construi paginile atunci când le solicitați, literalmente creăm fiecare pagină în avans, în cazul în care utilizatorul ar putea avea nevoie de ea. Face performanța super rapidă! Dar acest timp este acum transferat timpului de dezvoltare și publicare - crearea fiecărei pagini poate dura timp.

Aceasta nu este o problemă atât de mare cu site-urile mai mici, dar la scara Smashing Magazine, trebuie să ne gândim mai mult la acel moment, mai ales pentru ca oamenii să poată menține productivitatea ridicată în timp ce creează zilnic conținut activ.

Ceea ce a făcut Netlify a fost să creeze un folder mare /production-articles care conținea cea mai mare parte a numeroaselor 1000 de articole pe care le găzduiau deja. Apoi, a creat un director de lucru separat numit content/articles în care ar putea fi plasate articolele care au fost create și editate în mod activ.

Acest proces de construire a însemnat că toți cei care lucrau pe site lucrau cu un lot mai mic de articole pentru dezvoltare locală, nestingheriți de așteptarea întregii versiuni. Acest proces a fost gestionat printr-o sarcină înghițită de pregătire a articolelor de producție și l-a eliberat pe Hugo să se ocupe doar de ceea ce se lucra în mod activ.

Unul dintre dezavantajele acestei abordări este că încă necesită rularea întregii versiuni, făcând procesul lent. La o publicație mai mică, acest lucru ar conta probabil mai puțin, dar la scara lui Smashing, încetinește procesul de publicare.

API-uri open-source

La început, am menționat că, printre altele, Smashing a fost interesat să-și migreze soluția de comerț electronic existentă, să gestioneze comentariile în afara WordPress și să adauge funcționalități pentru autentificare. Toate aceste elemente de funcționalitate au fost construite cu soluții open-source pe care Netlify le menține, împărțindu-le în API-uri fără stat:

• GoTell
  Un API și un instrument de compilare pentru gestionarea unor cantități mari de comentarii.
• GoCommerce
  Un mic API bazat pe Go pentru site-uri de comerț electronic care se ocupă de comenzi și plăți.
• Go True
  Un mic API open-source scris în Golang, care poate acționa ca un serviciu API autonom pentru gestionarea înregistrării și autentificarea utilizatorilor pentru proiecte. Se bazează pe OAuth2 și JWT și se va ocupa de înscrierea utilizatorilor, autentificarea și datele personalizate ale utilizatorului.

Fiecare dintre aceste piese a necesitat migrare și factori unici și, deși nu sunt în domeniul de aplicare a acestui articol, toate sunt acoperite într-o carte gratuită pe care Matt a co-scris-o, numită „ Dezvoltare web modernă pe JAMstack ”. Vom face, de asemenea, câteva scufundări profunde ca aceasta - cu exemple utilizabile - în căutare și autentificare, în postările ulterioare.

Concluzie

Migrația s-a desfășurat în plin. zdrobitor? Ei... a mers bine. Smashing-ul nu a fost penalizat pentru propriul său succes - atunci când a apărut un articol popular, acestea puteau difuza conținutul în mod constant, nemaifiind eliberate de încărcături mari. Odată cu aceasta, trecerea la o infrastructură JAMstack a adus performanță și securitate mai bune.

Markus Seyfferth, fostul CEO al Smashing Magazine, a remarcat:

„Timpul pentru prima încărcare este mult mai rapid decât înainte... înainte trebuia să așteptăm ca fișierul HTML să fie servit timp de 800 ms , iar acum este de 80 ms .”

Acest proces a avut succes și, ca orice mare proiect de inginerie, lecțiile au fost învățate pe parcurs. În următorul articol din această serie, vom parcurge un tutorial și o demonstrație pentru ceea ce am recomanda, având în vedere ceea ce am învățat. Dacă doriți să vă modernizați dezvoltarea WordPress și să beneficiați de performanța și avantajele de securitate ale JAMstack, citiți mai departe!