Es war ein sonniger Tag in Cambridge im August 2017… Mitglieder des Jagex Web-Teams hatten gerade die responsiven 'Konto erstellen'-Seiten für RuneScape und Old School gestartet. Endlich konnten Spieler auf mobilen Geräten einfacher und schneller als je zuvor Konten über unsere Webseite erstellen. Unser responsives Framework nutzte das Beste aus unseren gewählten Sprachen, um eine elegante und saubere Benutzeroberfläche zu bieten. Wir machten uns die Vorteile des Layouts von Zurb Foundation 6 und des Atomic Design-Ansatzes zunutze, der es uns ermöglichte, unseren legacy Kontoerstellungsfluss innerhalb von zwei Wochen zu transformieren.

RuneScape Kontoerstellungsseite

Aber etwas fehlte…

Wir wussten, dass das System gut war, aber trotz unserer Fortschritte und der rasanten technischen Umsetzung konnten wir es nicht wirklich 'großartig' nennen. In der Welt der modernen Webentwicklung ist die Ladegeschwindigkeit der Seite alles und unser neues responsives System hatte immer noch Geschwindigkeitsprobleme!

Die Zeit unserer Benutzer ist eine sehr begrenzte Ressource. Wir müssen Informationen so schnell wie möglich zu ihnen bringen. Nielsen's Usability Engineering legt nahe, dass 10 Sekunden die Grenze sind, um die Aufmerksamkeit eines Nutzers zu halten. Schnell ladende Webseiten zuverlässig bereitzustellen, wurde aus mehreren Gründen immer schwieriger – und der prominenteste war alte Technologie.

Als Beispiel zeigen grobe Schätzungen, dass die Jagex Unternehmenswebsite in einigen Fällen über 20 Sekunden benötigte, um über eine Standard-3G-Verbindung von einem Nutzer in Kalifornien, USA, zu laden. Forschungen haben gezeigt, dass bei jeder Sekunde, die Ihre mobile Seite zum Laden benötigt, die Conversions um bis zu 20% sinken! Etwas musste sich ändern.

Jagex.com

Jagex wurde 1999 von den Gower-Brüdern gegründet – den Zauberern, die alles vom Game Engine und der Skriptsprache bis hin zu ihrer eigenen Web-Plattform gebaut haben. Der Umfang ihrer Architektur war beeindruckend; jedoch wurde die Wartung zunehmend mühsam. Selbst mit Verbesserungen wie unserem Wechsel zu Freemarker, das uns weit weg von der älteren, proprietären Template-Sprache WebScript gebracht hatte, war es an der Zeit, dass das Web-Team anfing, darüber nachzudenken, wie wir radikal schneller werden konnten.

WebScript-Code

Um unsere Leistung zu verbessern, mussten wir von vorn anfangen und neue Ansätze in Betracht ziehen, um unseren Tech-Stack an moderne Leistungsstandards anzupassen. Die Leute verwenden oft den Begriff 'Cloud' als Lösung für alle technischen Probleme. Wir fanden heraus, dass die Cloud zwar die Skalierbarkeit und möglicherweise die Geschwindigkeit bot, sie jedoch eine Kluft zu anderen Problemen wie Sicherheit, Kosten und Entwicklertraining öffnete.

Wie alle wirklich zukunftsorientierten Ideen würde unsere Lösung Zeit in Anspruch nehmen – viel Zeit. So viel, dass Außenstehende sagen könnten, dass es über lange Zeiträume so aussah, als würde kein Fortschritt erzielt. Die Suche nach unserer Web-Zukunft führte uns zu den großen 3 Cloud-Anbietern: Google Cloud, AWS und Microsoft Azure. Wir überprüften auch verschiedene verwaltete Lösungen wie Heroku und Netlify, bevor wir schließlich bei AWS blieben. Wir brauchten einen vertrauten Anbieter mit vorhandener Funktionalität und Flexibilität zur Expansion, wenn das Geschäft es erforderte, und das erweiterte Toolset von AWS passte perfekt zu unseren Anforderungen.

Aber Infrastrukturen waren nicht das einzige Problem, das wir lösen mussten. Um dynamische Webseiten auf unserer aktuellen Plattform bereitzustellen, benötigten wir Entwickler mit Kenntnissen in Java, Freemarker, CSS und JS, um eine Seite zu erstellen, die für Endbenutzer geeignet war. Dies erforderte oft zwei Entwickler (Frontend und Backend) pro Seite, was häufig unsere Projektempfindlichkeit verlangsamte.

Wie könnten wir das lösen? Was wäre, wenn wir eine Sprache für das Backend, das Templating und das Frontend-Verhalten verwenden könnten? Nun, wir begeben uns in die Welt von JavaScript als Backend-Sprache (wir führen die Logik aus, bevor wir überhaupt die Seite zeichnen). Wir konnten spüren, wie sich alle Backend-Entwickler beim bloßen Vorschlag, so etwas zu tun, zusammenzogen – der Ruf von JavaScript ist vielleicht zu Unrecht vorbelastet. Die Wahrheit ist, es ist wie bei den meisten Sprachen - verwenden Sie es kreativ und richtig und Sie können unglaubliche Aufgaben damit erledigen – aber mit großer Macht kommt große Verantwortung. Wir mussten von der Qualität unseres Codes überzeugt sein und um dies zu erleichtern, entschieden wir uns, TypeScript zu verwenden. In TypeScript haben alle unsere Variablen und Funktionen strenge Typisierung, die verhindert, dass die faulen JavaScript-Probleme eindringen.

Wir implementierten auch EJS als Templating-Sprache anstelle von Freemarker. Das bedeutete, dass sowohl die Backend- als auch die Templating-Logik JavaScript-Methoden verwendeten. Daher konnten wir die Abhängigkeit von Entwicklern reduzieren, die verschiedene Sprachen kennen mussten.

Schließlich implementierten wir SCSS mit der neuesten Version von Zurb Foundation, um die Seitenkosmetik zu handhaben und komplizierte Layouts mit wiederverwendbarem und organisiertem CSS zu erstellen. Ein Node.js-Webanwendungs-Framework fasst alles zusammen, um unsere Webseiten der Welt zu präsentieren.

Um die Leistung unserer neuen Implementierung genau zu testen, wählten wir eine kleine Seite als Benchmark aus. Die Unternehmenswebseite war der perfekte Kandidat und erlaubte uns, die Leistung mit unserem älteren System zu vergleichen, ohne den Zugriff auf das Spiel zu beeinträchtigen.

Unsere Ergebnisse waren sehr ermutigend, da wir über 40% unserer gesamten Ladezeit eingespart haben. Die neue Plattform funktionierte, aber wir benötigten ein CMS dahinter, um anderen Mitarbeitern zu ermöglichen, den Seiteninhalt ohne die Notwendigkeit eines Entwicklers zu ändern.

Das CMS, für das wir uns schließlich entschieden, war das mächtige Contentful. Die Leistungsfähigkeit und Vielseitigkeit dieses CMS ermöglichten es uns, den Seiteninhalt schnell zu ändern, während wir die Flexibilität beibehielten. Mit all dem zusammen tauften wir das Projekt Merlin – die Zukunft der Jagex-Technologiedienste.

Sie lesen tatsächlich einen der ersten Blogartikel, die von der Merlin-Plattform bereitgestellt werden, zusammen mit dem Rest von Jagex.com und RuneFest.com. Kurz darauf begannen wir auch, RuneScape.com auf die neue Plattform mit der World Out of Time-Mini-Seite zu migrieren.

World Out of Time Mini-Seite

Die Zukunft unseres Tech-Stacks sieht immer heller aus, während wir 2019 mit mehr Wissen und Verständnis als je zuvor durchstarten. Wir machen große Fortschritte, aber stehen fest auf dem Boden.

Wollen Sie uns helfen, die Zukunft von Jagex Technologie mitzugestalten? Gehen Sie auf die Karriere-Seite für die aktuellen Stellenangebote und helfen Sie uns, die Art und Weise zu verändern, wie wir Inhalte bereitstellen.