Wie Smashing Magazine Inhalte verwaltet: Migration von WordPress zu JAMstack

Dieser Artikel wurde freundlicherweise von unseren lieben Freunden bei Netlify unterstützt, einer All-in-One-Plattform zur Automatisierung moderner Webprojekte. Danke!

Jedes Mal, wenn Entwickler über WordPress sprechen, ändert sich ihr Marktanteil in Prozent. „ 20 % aller Seiten sind auf WordPress! ” “ 40 % aller Seiten sind auf WordPress! „Was auch immer der Prozentsatz ist, die Botschaft ist dieselbe: In Bezug auf die Akzeptanz ist WordPress MASSIV.

Warum also sollte eine Website, die WordPress verwendet, bei dieser Art von Akzeptanz den Wechsel zu JAMstack in Betracht ziehen? In dieser zweiteiligen Artikelserie behandeln wir anhand einer Fallstudie genau der Website, von der Sie gerade lesen, wie eine tatsächliche WordPress-Migration aussieht.

Wir werden über die Gewinne und Verluste sprechen, über die Dinge, von denen wir uns wünschten, wir hätten sie früher gewusst, und was uns überrascht hat. Und dann folgen wir mit einer technischen Demonstration eines möglichen Migrationspfads – nicht vollständig von WordPress weg – sondern wie Sie entkoppeltes WordPress so bedienen können, dass Sie das Beste aus beiden Welten haben: eine JAMstack-Implementierung von WordPress, die Ihnen alles bietet die Leistungsfähigkeit ihres Dashboards und ihrer Funktionalität mit besserer Leistung und Sicherheit.

Lassen Sie uns graben!

Warum?

2015 fachsimpelten Netlify-Mitbegründer Mathias Biilmann und Smashing-Gründer Vitaly Friedman. Als die JAMstack-Architektur anfing, Runden zu drehen, interessierte sich Smashing mehr für die Idee des Stacks. Vitaly und Markus (ehemaliger Geschäftsführer bei Smashing) fragten Matt, was passieren würde, wenn Smashing von ihrer traditionellen WordPress/LAMPstack-Site zu einer JAMstack-Architektur migrieren würde.

Als Experiment kratzte Matt den gesamten HTML-Code von Smashing und hostete ihn auf Netlify, wobei er den Inhalt statisch von einem CDN lieferte. Die Ergebnisse waren überzeugend – die statische Version ist im Durchschnitt mehr als sechsmal so schnell!

Diese Art von Architektur funktioniert zum Teil deshalb so gut, weil Seiten nicht nach Bedarf kompiliert werden, während Sie sie besuchen. Da Sie vorgefertigte Inhalte direkt von einem Content Delivery Network bereitstellen, ist die Website bereits „da“ und bereit für den Benutzer.

Da Sie über CDN dienen, können Sie die Inhalte auch auf der ganzen Welt verteilen – näher an potenziellen Besuchern. Es gibt keinen zentralen Ausgangspunkt, was für jede Online-Publikation, die für alle ihre Leser schnell sein möchte, von entscheidender Bedeutung ist.

Die Bühne war also bereitet. Smashing Magazine migrierte auf den JAMstack – insbesondere auf Netlify als Plattform. In den 10 Jahren seines Bestehens hatte sich Smashing von einer kleinen Online-Publikation zu einem riesigen WordPress-Blog entwickelt, der Dinge wie Bücher, Konferenztickets und Workshops verkaufte.

Es gab ein paar Teile dieser Seite:

• WordPress-Blog
• Rails Stellenbörse
• Shopify-Shop
• Ein weiteres CMS für die Konferenzseite

Als Netlify mit der Migration begann, litt die Website unter einigen Leistungsproblemen, die von 20.000 Kommentaren und Tausenden von Artikeln belastet wurden. Smashing interessierte sich auch für die Authentifizierung als Teil eines neuen Abonnementplans sowie für eine Neugestaltung für ein moderneres Aussehen.

Verlässlichkeit

Smashing erreicht regelmäßig, wovon andere Plattformen träumen: Artikel, die von einer riesigen Community geteilt werden. Wenn jedoch für einen Beitrag ein Wendepunkt des Datenverkehrs erreicht wurde, hatte Smashing regelmäßig Probleme mit Ausfällen. Um dies abzumildern, wurde die starke Nutzung von WordPress-Plugins in ihren Stack aufgenommen, aber sie hatten immer noch Mühe, gute Betriebszeitmetriken beizubehalten.

Der Wechsel zu Netlify ermöglichte es dem Smashing-Team, Datenbankverbindungsfehler zu vermeiden und sich keine Gedanken über Ausfallzeiten zu machen, selbst wenn ein Artikel sehr viel Verkehr verzeichnete. Warum? Denn bei der Bereitstellung ohne Server müssen die vorgefertigten Inhalte nicht generiert und bereitgestellt werden – sie sind bereits vorhanden und können angezeigt werden. An Ort und Stelle wird nichts angefordert, außer der gesamten, statischen Seite.

Durch die Bereitstellung über CDN konnte Smashing auch in Bezug auf die Sicherheit etwas ruhiger schlafen. wp-login.php ist seit langem eine Quelle von Sicherheitslücken und Angriffsvektoren. Auf vorgefertigte Inhalte kann nicht auf die gleiche Weise zugegriffen werden und Sicherheitslücken sind nicht so allgegenwärtig.

Cache-Invalidierung

Smashing hatte jedes WordPress-Caching-Plugin durchlaufen, mit unterschiedlichen Ergebnissen und vielen Problemen. Vitaly Friedman von Smashing erwähnt,

„Die Hauptprobleme, die wir hatten, bezogen sich auf ‚Error Establishing Database Connection‘, den wir alle zwei Wochen hatten, und wir haben buchstäblich jedes einzelne WordPress-Caching-Plugin auf dem Markt ausprobiert. Die Leistung war (insgesamt) ziemlich in Ordnung, aber wir wollten sie weiter verbessern. Außerdem wollten wir die Mitgliedschaft starten und all die verschiedenen Angebote – Konferenzen, Stellenausschreibungen, Artikel, Bücher, eBooks – mit einer einzigen Plattform verbinden, und es war bemerkenswert schwierig, dies mit WordPress zu erreichen.“

Der Wechsel zu Netlify ermöglichte es dem Smashing-Team, eine sofortige Cache-Invalidierung zu sehen und gleichzeitig zwischengespeicherte und performante Inhalte ohne zusätzlichen Overhead bereitzustellen.

Wenn Sie eine Site bereitstellen, werden HTML-Dateien auf dem CDN von Netlify gehostet. Es ist für eine hohe Cache-Hit-Rate und eine schnelle Zeit bis zum ersten Byte optimiert, während es gleichzeitig in der Lage ist , alle geänderten HTML-Dateien sofort ungültig zu machen. Netlify erfasst auch alle Links zu Assets wie CSS-Dateien, Bildern, Schriftarten oder JS-Dateien und versorgt Smashing mit Caching-Headern, die sie für immer zwischenspeichern. Das Fingerprinting garantiert, dass sie einzigartig sind und dass, wenn Sie eine neue Version aktualisieren, stattdessen die neuere Version bereitgestellt wird.

Arbeitsablauf

Betrachtet man das bestehende Setup, so war ein wesentlicher Grund für die Migration einfach die Vereinheitlichung der bestehenden Eigenschaften. Der Kontextwechsel zwischen all diesen verschiedenen Tech-Stacks und Setups wurde zu einem schwierigen Wartungsproblem, das die Ingenieure vor eine Herausforderung stellte.

Als zuvor ihre Infrastruktur auf so viele verschiedene Systeme aufgeteilt war, vereinheitlichte dieser Migrationsprozess auch alles , sodass die Hauptwebsite, die Konferenzwebsite, die Abonnements und der E-Commerce-Bereich alle zusammenarbeiteten, anstatt separat mit verschiedenen Stacks verwaltet zu werden. Dies trug dazu bei, die Entwicklungskosten niedrig zu halten und die Entwicklererfahrung bei der konsistenten Arbeit an allen Objekten zu halten.

Das WordPress-Migrationsstück erwies sich als das größte und heikelste. Netlify hat versucht, die Daten aus dem WP-Exporter zu exportieren, nur um festzustellen, dass der Inhalt Einbettungen hatte, die beibehalten werden mussten, oder manchmal durch Plugins geändert wurde. Um die Parität mit dem, was sich auf der Website befand, aufrechtzuerhalten, wurde eine Reihe von Scrapern geschrieben, die nach Artikeln, Assets, Kommentaren und der Homepage aufgeschlüsselt sind.

Sobald das geschrieben und transformiert war, wurde es in ein neues Repo in GitHub geladen und stattdessen Netlify CMS verwendet. Was Netlify CMS einzigartig macht, ist, dass es leicht ist und Inhaltseditoren in einen Git-Workflow integriert – was bedeutet, dass es Markdown-Dateien buchstäblich aus einem Git-Repo anstelle einer Datenbank zieht und bereitstellt. Darüber hinaus ist Netlify CMS plattformunabhängig und funktioniert mit (fast) allen statischen Site-Generatoren und Sites, die in GitHub gespeichert sind.

Damals arbeitete Sara Soueidan für Smashing als freiberufliche Frontend-Entwicklerin an deren Redesign. Sie erstellte eine Bibliothek mit Komponenten, um die Front-End-Architektur aufzubauen, und bemerkte, wie viel einfacher es sei, damit zu arbeiten, da sie direkt in Git arbeite, selbst wenn sie mit dem CMS arbeite.

„Alles, was ich in das Repository geschoben habe, wird direkt auf die Musterbibliothek angewendet, was bedeutet, dass Sie nicht zwei verschiedene Komponentensätze verwalten müssen ... diese Art von Kontinuität war großartig! Alles, was ich tun muss, ist HTML, CSS und JavaScript zu schreiben und in das Repo zu pushen, und alles funktioniert wie von Zauberhand. Der Workflow war fantastisch.“

All dies gesagt, Netlify CMS kann manchmal zu leichtgewichtig für einen Anwendungsfall mit so hohem Datenverkehr und Skalierung sein. Smashing hat regelmäßig Gastautoren und eine vollständige Redaktion. Einige der reichhaltigen Funktionen, die WordPress bietet, sind wirklich hilfreich für diese Art von hochgradig kollaborativen Umgebungen.

Aus diesem Grund führen wir Sie im folgenden Tutorial durch ein Headless-Modell , bei dem Sie immer noch die Vorteile des WordPress-Dashboards für Inhaltsersteller nutzen können, aber WordPress über die API verwenden und die Entwicklung so einfach auf einen Git-zentrierten Workflow setzen lassen auch für Entwickler zu warten. Bleib dran!

Framework-Auswahl

In dem ersten Prototyp, den Matt Biilmann erstellte, schrieb er alles in minimalem Preact, gepaart mit Hugo, da er sich sehr auf die Leistung konzentrierte. Er benutzte nur Requisiten und hielt alles sehr leicht. Als er das Projekt an den Entwickler von Smashing, Ilya Pukhalski, weitergab, stellte er fest, dass Preact einige Funktionen fehlten, die ihnen fehlten, um das Ökosystem von React zu erschließen. Schließlich überwogen die Vorteile von Redux und anderen Bibliotheken die Kosten.

Wenn er jetzt darüber nachdenkt, sagt Matt, er hätte Vue verwendet, das damals nicht ganz den Marktanteil hatte (ich schwöre, ich habe ihn nicht dazu aufgefordert, das zu sagen). Ich stellte die offensichtliche Frage: Warum nicht Svelte? Da leistungsorientierte Leute dazu neigen, nach dieser Bibliothek zu greifen. Er erwähnte, dass Svelte noch nicht ganz das Ökosystem hat, das Vue hat.

Als Matt darüber nachdenkt, ob er Hugo noch verwendet hätte oder nicht, sagt er, dass er Hugo liebt, aber was er bei diesem Projekt besonders schwierig fand, war, dass es nicht genug Plugin-System hatte – das Erstellen von Werbebannern und so weiter Diese Natur war bei Hugo nicht programmierbar genug und er musste Skripte einfügen, um dies zu erreichen. Diese Skripte neigten dazu, den Erstellungsprozess zu verlangsamen. Nichtsdestotrotz verwenden wir Hugo immer noch für unsere eigene Seite auf netlify.com und lieben es – dieser Vorbehalt ist besonders speziell auf die Bedürfnisse von Smashings Seite zugeschnitten.

Wenn er es noch einmal machen könnte, würde er entweder Eleventy wählen, das über umfangreiche Möglichkeiten zum Erstellen von Plugins und anderen erweiterbaren Skripten verfügt. Oder wenn er Vue verwendet hätte, hätte Nuxt ihm einige nette Plugin-Funktionen angeboten und gleichzeitig eine gute Wahl für dieses Framework gemacht, da es serverseitiges Rendering, Routing und statische Generierung bietet.

Aufbau großer Websites

Es gab ein Problem, das bei der Arbeit mit einer so großen Site wie Smashing auftauchte, und vielleicht können Sie bereits herausfinden, was es ist, wir haben es gerade berührt. Es stimmt, dass die Leistung bei jeder großen Website mit vorgefertigten Seiten, die auf einem CDN bereitgestellt werden, immer noch großartig ist, da wir nichts spontan für die Benutzer erstellen.

Dieser Vorteil kann jedoch nur eintreten, wenn die Website vorgefertigt ist, und dieser Prozess kann zeitaufwändig sein. Während traditionellere Websites die Seiten erstellen, wenn Sie sie anfordern, erstellen wir buchstäblich jede einzelne Seite im Voraus, nur für den Fall, dass der Benutzer sie benötigt. Es macht die Leistung superschnell! Aber diese Zeit wird jetzt auf Entwicklungs- und Veröffentlichungszeit ausgelagert – das Erstellen jeder Seite kann einige Zeit in Anspruch nehmen.

Bei kleineren Websites ist dies kein so großes Problem, aber bei der Größenordnung von Smashing Magazine müssen wir etwas mehr über diese Zeit nachdenken, insbesondere damit die Mitarbeiter ihre Produktivität hoch halten können, während sie täglich aktiv Inhalte erstellen.

Netlify hat einen großen /production-articles Ordner erstellt, der den Großteil der vielen 1000 Artikel enthielt, die sie bereits hosten. Erstellen Sie dann ein separates Arbeitsverzeichnis namens content/articles , in dem die Artikel, die aktiv erstellt und bearbeitet werden, abgelegt werden können.

Dieser Build-Prozess bedeutete, dass jeder, der an der Site arbeitete, mit einem kleineren Batch von Artikeln für die lokale Entwicklung arbeitete, ungehindert durch das Warten auf den gesamten Build. Dieser Prozess wurde durch eine Gulp-Aufgabe verwaltet, um die Produktionsartikel vorzubereiten, und gab Hugo die Möglichkeit, nur das zu bearbeiten, woran aktiv gearbeitet wurde.

Einer der Nachteile dieses Ansatzes besteht darin, dass immer noch der gesamte Build ausgeführt werden muss, was den Prozess verlangsamt. Bei einer kleineren Veröffentlichung wäre dies wahrscheinlich weniger wichtig, aber bei Smashing verlangsamt es den Veröffentlichungsprozess.

Open-Source-APIs

Am Anfang erwähnten wir, dass Smashing unter anderem daran interessiert war, ihre bestehende E-Commerce-Lösung zu migrieren, Kommentare außerhalb von WordPress zu verarbeiten und Funktionen für die Authentifizierung hinzuzufügen. Alle diese Funktionalitäten wurden mit Open-Source-Lösungen entwickelt, die Netlify pflegt und in zustandslose APIs aufteilt:

• GehTell
  Ein API- und Build-Tool zur Verarbeitung großer Mengen von Kommentaren.
• GoCommerce
  Eine kleine Go-basierte API für E-Commerce-Websites, die Bestellungen und Zahlungen abwickelt.
• GoTrue
  Eine kleine in Golang geschriebene Open-Source-API, die als eigenständiger API-Dienst für die Abwicklung der Benutzerregistrierung und -authentifizierung für Projekte fungieren kann. Es basiert auf OAuth2 und JWT und verarbeitet Benutzeranmeldung, Authentifizierung und benutzerdefinierte Benutzerdaten.

Jedes dieser Teile erforderte eine Migration und eigene einzigartige Faktoren, und obwohl sie in diesem Artikel nicht behandelt werden, werden sie alle in einem kostenlosen Buch mit dem Titel „ Moderne Webentwicklung auf dem JAMstack “ behandelt, das Matt mitgeschrieben hat. Wir werden auch einige tiefgehende Tauchgänge wie diesen – mit brauchbaren Beispielen – in die Suche und Authentifizierung in späteren Posts einführen.

Fazit

Die Migration verlief reibungslos. Umwerfend? Äh… es lief gut. Smashing wurde nicht für seinen eigenen Erfolg bestraft – wenn ein beliebter Artikel auftauchte, konnten sie den Inhalt konsistent bereitstellen und nicht mehr über große Lasten springen. Gleichzeitig brachte die Umstellung auf eine JAMstack-Infrastruktur eine bessere Leistung und Sicherheit.

Markus Seyfferth, ehemaliger CEO des Smashing Magazine, bemerkte:

„Die Zeit bis zum ersten Laden ist so viel schneller als zuvor … vorher mussten wir 800 ms auf die Bereitstellung der HTML-Datei warten und jetzt sind es 80 ms .“

Dieser Prozess war erfolgreich und wie bei jedem großen Ingenieurprojekt wurden dabei Lehren gezogen. In diesem nächsten Artikel dieser Serie führen wir ein Tutorial und eine Demo durch, die zeigen, was wir aufgrund unserer Erkenntnisse empfehlen würden. Wenn Sie Ihre WordPress-Entwicklung modernisieren und die Leistungs- und Sicherheitsvorteile von JAMstack nutzen möchten, lesen Sie weiter!