Come Smashing Magazine gestisce i contenuti: migrazione da WordPress a JAMstack

Questo articolo è stato gentilmente supportato dai nostri cari amici di Netlify, una piattaforma all-in-one per automatizzare i moderni progetti web. Grazie!

Ogni volta che gli sviluppatori parlano di WordPress, la percentuale della loro quota di mercato cambia. “ Il 20% di tutti i siti è su WordPress! ” “ Il 40% di tutti i siti è su WordPress! Qualunque sia la percentuale, il messaggio è lo stesso: in termini di adozione, WordPress è MASSICCIO.

Allora perché, con questo tipo di adozione, un sito che utilizza WordPress dovrebbe considerare di passare a JAMstack? In questa serie di articoli in due parti, tratteremo l'aspetto di una migrazione effettiva di WordPress, utilizzando un case study dello stesso sito da cui stai leggendo in questo momento.

Parleremo dei guadagni e delle perdite, delle cose che vorremmo sapere prima e di ciò di cui siamo rimasti sorpresi. E poi lo seguiremo con una dimostrazione tecnica di un possibile percorso di migrazione, non completamente fuori da WordPress, ma come puoi servire WordPress disaccoppiato in modo da poter avere il meglio di entrambi i mondi: un'implementazione JAMstack di WordPress che ti offre tutto la potenza della loro dashboard e funzionalità, con prestazioni e sicurezza migliori.

Scendiamo!

Come mai?

Nel 2015, il co-fondatore di Netlify Mathias Biilmann e il fondatore di Smashing Vitaly Friedman hanno parlato di negozio. Quando l'architettura JAMstack ha iniziato a girare, Smashing è diventato più interessato all'idea dello stack. Vitaly e Markus (ex amministratore delegato di Smashing) hanno chiesto a Matt cosa sarebbe successo se Smashing fosse migrato dal loro tradizionale sito WordPress/LAMPstack a un'architettura JAMstack.

Come esperimento, Matt ha raschiato tutto l'HTML da Smashing e lo ha ospitato su Netlify, distribuendo il contenuto in modo statico da una CDN. I risultati sono stati convincenti: la versione statica è in media sei volte più veloce!

Questo tipo di architettura funziona così bene in parte perché le pagine non vengono compilate su richiesta mentre le visiti. Poiché stai offrendo contenuti predefiniti direttamente da una rete di distribuzione di contenuti , il sito è già "lì" e pronto per l'utente.

Dal momento che stai servendo tramite CDN, puoi anche distribuire i contenuti in tutto il mondo, più vicino ai potenziali visitatori. Non c'è un punto di origine centrale, che è vitale nel caso di qualsiasi pubblicazione online che vuole essere veloce per tutti i suoi lettori.

Quindi il palcoscenico era pronto. Smashing Magazine è migrato su JAMstack, in particolare su Netlify come piattaforma. Nei suoi 10 anni di attività, Smashing è passata da una piccola pubblicazione online a un enorme blog WordPress, vendendo cose come libri, biglietti per conferenze e workshop.

C'erano alcuni pezzi di questo sito:

• blog WordPress
• Bacheca dei lavori di Rails
• Negozio Shopify
• Un altro CMS per il sito della conferenza

Quando Netlify ha iniziato la migrazione, il sito presentava alcuni problemi di prestazioni, appesantiti da 20.000 commenti e migliaia di articoli. Smashing era anche interessato all'autenticazione come parte di un nuovo piano di abbonamento, nonché a una riprogettazione per un look più moderno.

Affidabilità

Smashing ottiene regolarmente ciò che le altre piattaforme sognano: articoli ampiamente condivisi attraverso un'enorme comunità. Tuttavia, quando è stato raggiunto un punto critico del traffico per un post, Smashing ha avuto regolarmente problemi di interruzioni. Per mitigare questo, l'uso massiccio dei plugin di WordPress è stato introdotto nel loro stack, ma hanno comunque faticato a mantenere buone metriche di uptime.

Il passaggio a Netlify ha consentito al team di Smashing di evitare errori di connessione al database e di non preoccuparsi dei tempi di inattività anche quando un articolo ha registrato un'enorme quantità di traffico. Come mai? Perché quando viene servito senza un server, il contenuto predefinito non deve essere generato e servito: esiste già, pronto per essere visualizzato. Non viene richiesto nulla in loco tranne l'intera pagina statica.

Il servizio tramite CDN ha anche permesso a Smashing di dormire un po' più facilmente in termini di sicurezza. wp-login.php è stato a lungo una fonte di falle di sicurezza e vettori di attacco. Non è possibile accedere ai contenuti predefiniti nello stesso modo e le falle di sicurezza non sono così onnipresenti.

Invalidamento della cache

Smashing ha passato in rassegna tutti i plugin di memorizzazione nella cache di WordPress, con risultati diversi e molti problemi. Vitaly Friedman di Smashing cita,

"I problemi principali che abbiamo riscontrato erano relativi all'"Errore durante la creazione della connessione al database" che continuavamo ad avere ogni due settimane e abbiamo letteralmente provato ogni singolo plug-in di memorizzazione nella cache di WordPress disponibile. La prestazione è stata abbastanza buona (nel complesso), ma stavamo cercando di migliorarla ulteriormente. Inoltre, volevamo lanciare l'iscrizione e collegare tutte le diverse offerte - conferenze, offerte di lavoro, articoli, libri, eBook - con un'unica piattaforma ed è stato straordinariamente difficile da raggiungere con WordPress in gioco".

Il passaggio a Netlify ha consentito al team di Smashing di vedere l'invalidazione istantanea della cache mentre serve anche contenuti memorizzati nella cache e performanti, senza costi aggiuntivi.

Quando distribuisci un sito, i file HTML sono ospitati sulla CDN di Netlify. È ottimizzato per un'elevata velocità di accesso alla cache e tempi rapidi per il primo byte, pur essendo in grado di invalidare istantaneamente tutti i file HTML che sono stati modificati. Netlify rileva anche tutti i collegamenti a risorse come file CSS, immagini, caratteri o file JS e offre Smashing con intestazioni di memorizzazione nella cache che le memorizzano nella cache per sempre. L'impronta digitale garantisce che siano univoci e che se aggiorni una nuova versione, venga invece pubblicata la versione più recente.

Flusso di lavoro

Osservando la configurazione esistente, una delle ragioni principali della migrazione era semplicemente l'unificazione delle proprietà esistenti. La necessità di modificare il contesto tra tutti questi diversi stack tecnologici e configurazioni è diventato un difficile problema di manutenzione che ha incaricato gli ingegneri.

Quando in precedenza la loro infrastruttura era suddivisa tra così tanti sistemi diversi, questo processo di migrazione ha anche unificato tutto , mantenendo il sito principale, il sito della conferenza, la sezione abbonamenti e e-commerce tutti lavorando insieme invece di essere mantenuti separatamente con stack diversi. Ciò ha contribuito a mantenere bassi i costi di sviluppo e l'esperienza dello sviluppatore lavorando su tutte le proprietà in modo coerente.

Il pezzo di migrazione di WordPress si è rivelato il più grande e delicato. Netlify ha provato a esportare i dati dall'esportatore WP, solo per scoprire che il contenuto aveva incorporamenti che dovevano essere conservati o, a volte, veniva alterato dai plugin. Per mantenere la parità con quanto c'era nel sito, sono stati scritti una serie di scraper, suddivisi per articoli, asset, commenti e homepage.

Una volta scritto e trasformato, è stato caricato in un nuovo repository in GitHub e al suo posto è stato utilizzato Netlify CMS. Ciò che rende unico Netlify CMS è che è leggero e integra gli editor di contenuti in un flusso di lavoro Git, il che significa che estrarrà e servirà letteralmente file markdown da un repository git anziché da un database. Inoltre, Netlify CMS è indipendente dalla piattaforma e funziona con (quasi) tutti i generatori di siti statici e i siti archiviati in GitHub.

A quel tempo, Sara Soueidan ha lavorato per Smashing come sviluppatore front-end freelance per la loro riprogettazione. Ha creato una libreria di componenti per costruire l'architettura front-end e ha osservato quanto fosse più semplice lavorare perché lavorava direttamente in git, anche quando lavorava con il CMS.

“Tutto ciò che ho inviato al repository viene applicato direttamente alla libreria di modelli, il che significa che non è necessario mantenere due diversi set di componenti... questo tipo di continuità è stato fantastico! Tutto quello che devo fare è scrivere HTML, CSS e JavaScript e inviare al repository e tutto funziona come per magia. Il flusso di lavoro è stato fantastico".

Detto questo, Netlify CMS a volte può essere troppo leggero per un caso d'uso ad alto traffico e scalabilità. Smashing ha regolarmente autori ospiti e una redazione completa. Alcune delle ricche funzionalità offerte da WordPress sono davvero utili per questo tipo di ambienti altamente collaborativi.

Ecco perché nel seguente tutorial, ti guideremo attraverso un modello senza testa , in cui puoi ancora sfruttare i vantaggi della dashboard di WordPress per i creatori di contenuti, ma utilizzare WordPress tramite API e fare in modo che lo sviluppo si basi su un flusso di lavoro git-centrico così facile anche per gli sviluppatori da mantenere. Rimani sintonizzato!

Scelte del quadro

Nel prototipo iniziale creato da Matt Biilmann, scriveva tutto in un minimo Preact, in coppia con Hugo, poiché era molto concentrato sulle prestazioni. Ha solo usato oggetti di scena e ha mantenuto tutto molto leggero. Quando ha lasciato che il progetto fosse mantenuto dallo sviluppatore di Smashing, Ilya Pukhalski, ha scoperto che a Preact mancavano alcune funzionalità che mancavano per attingere all'ecosistema di React. Alla fine, i vantaggi di Redux e di altre librerie hanno superato il costo.

Riflettendo ora, Matt dice che avrebbe usato Vue, che all'epoca non deteneva una quota di mercato (giuro che non l'ho spinto a dirlo). Ho posto la domanda ovvia: perché non Svelte? Poiché le persone attente alle prestazioni tendono a raggiungere quella libreria. Ha detto che Svelte non ha ancora l'ecosistema che Vue ha.

Quando Matt riflette sul fatto che avrebbe ancora usato Hugo, dice che ama Hugo, ma ciò che ha trovato difficile per questo progetto in particolare è stato che non aveva abbastanza un sistema di plug-in: creare banner pubblicitari e cose di quella natura non era abbastanza programmabile con Hugo e aveva bisogno di iniettare script per realizzarlo. Questi script tendevano a rallentare il processo di compilazione. Detto questo, utilizziamo ancora Hugo per il nostro sito su netlify.com e lo adoriamo: questo avvertimento è estremamente particolare per le esigenze del sito di Smashing in particolare.

Se potesse farlo di nuovo, potrebbe scegliere Eleventy, che ha funzionalità avanzate in termini di creazione di plug-in e altri script estensibili. Oppure, se stesse usando Vue, Nuxt gli avrebbe offerto alcune belle funzionalità di plugin pur essendo una buona scelta per quel framework, offrendo rendering lato server, routing e generazione statica.

Costruire grandi siti

C'è stato un problema che è emerso lavorando con un sito grande come Smashing e forse puoi già capire di cosa si tratta, l'abbiamo appena toccato. È vero che con qualsiasi sito di grandi dimensioni di pagine predefinite pubblicate su una CDN, le prestazioni sono comunque ottime perché non stiamo costruendo nulla al volo per gli utenti.

Ma questo vantaggio può verificarsi solo se il sito è pre-costruito e quel processo può richiedere molto tempo. Mentre i siti più tradizionali costruiranno le pagine quando le richiedi, stiamo letteralmente creando ogni singola pagina in anticipo nel caso in cui l'utente possa averne bisogno. Rende le prestazioni super veloci! Ma quel tempo è ora scaricato sul tempo di sviluppo e pubblicazione: la creazione di ogni pagina può richiedere tempo.

Questo non è tanto un problema con i siti più piccoli, ma su scala di Smashing Magazine, dobbiamo pensare un po' di più a quel tempo, soprattutto in modo che le persone possano mantenere alta la produttività mentre creano attivamente contenuti quotidianamente.

Ciò che Netlify ha fatto è stato creare una grande cartella /production-articles che conteneva la maggior parte delle migliaia di articoli che stavano già ospitando. Quindi, è stata creata una directory di lavoro separata chiamata content/articles in cui potevano essere inseriti gli articoli che venivano attivamente creati e modificati.

Questo processo di compilazione significava che tutti coloro che stavano lavorando sul sito stavano lavorando con un batch più piccolo di articoli per lo sviluppo locale, senza ostacoli nell'attesa dell'intera build. Questo processo è stato gestito da un'attività di sorso per preparare gli articoli di produzione e ha permesso a Hugo di gestire solo ciò su cui si stava attivamente lavorando.

Uno degli svantaggi di questo approccio è che richiede ancora l'esecuzione dell'intera build, rallentando il processo. In una pubblicazione più piccola, questo probabilmente importerebbe meno, ma su scala di Smashing, rallenta il processo di pubblicazione.

API open source

All'inizio, abbiamo menzionato che, tra le altre cose, Smashing era interessato a migrare la propria soluzione di e-commerce esistente, gestire i commenti al di fuori di WordPress e aggiungere funzionalità per l'autenticazione. Tutte queste funzionalità sono state create con soluzioni open source che Netlify mantiene, suddividendole in API stateless:

• Vai a dire
  Un'API e uno strumento di creazione per la gestione di grandi quantità di commenti.
• GoCommerce
  Una piccola API basata su Go per siti di e-commerce che gestisce ordini e pagamenti.
• Vai Vero
  Una piccola API open source scritta in Golang che può fungere da servizio API autonomo per la gestione della registrazione degli utenti e dell'autenticazione per i progetti. Si basa su OAuth2 e JWT e gestirà la registrazione utente, l'autenticazione e i dati utente personalizzati.

Ognuno di questi pezzi ha richiesto la migrazione e fattori unici propri e, sebbene non siano compresi nell'ambito di questo articolo, sono tutti trattati in un libro gratuito che Matt ha co-scritto chiamato " Modern Web Development on the JAMstack ". Faremo anche alcuni approfondimenti come questo - con esempi utilizzabili - nella ricerca e nell'autenticazione, nei post successivi.

Conclusione

La migrazione è andata a gonfie vele. Incredibilmente? Ehm... è andata bene. Smashing non è stato penalizzato per il suo stesso successo: quando è arrivato un articolo popolare, potevano servire il contenuto in modo coerente, senza più salvare grandi carichi. Insieme a questo, il passaggio a un'infrastruttura JAMstack ha portato prestazioni e sicurezza migliori.

Markus Seyfferth, ex CEO di Smashing Magazine, ha osservato:

"Il tempo per il primo caricamento è molto più veloce di prima... prima dovevamo aspettare che il file HTML venisse servito per 800 ms e ora è 80 ms ."

Questo processo ha avuto successo e, come ogni grande progetto di ingegneria, le lezioni sono state apprese lungo il percorso. In questo prossimo articolo di questa serie, analizzeremo un tutorial e una demo per ciò che raccomandiamo dato ciò che abbiamo imparato. Se desideri modernizzare il tuo sviluppo WordPress e sfruttare i vantaggi in termini di prestazioni e sicurezza di JAMstack, continua a leggere!