C'était une journée ensoleillée à Cambridge en août 2017… les membres de l'équipe Web de Jagex venaient de lancer les pages de création de compte réactives pour RuneScape et Old School. Enfin, les joueurs sur des appareils mobiles pourraient créer des comptes sur notre site web plus facilement et rapidement que jamais auparavant. Notre cadre réactif utilisait le meilleur de nos langages choisis pour fournir une interface élégante et claire. Nous profitions de la mise en page en grille de Zurb Foundation 6 et de l'approche Atomic Design qui nous permettait de transformer notre flux de création de compte hérité en deux semaines.

Page de création de compte RuneScape

Mais il manquait quelque chose…

Nous savions que le système était bon, mais malgré nos progrès et notre exécution technique rapide, nous ne pouvions pas le qualifier de vraiment 'génial'. Dans le monde du développement web moderne, la vitesse de chargement des pages est tout, et notre nouveau système réactif manquait encore de vitesse!

Le temps de nos utilisateurs est une ressource très limitée. Nous avons besoin de leur fournir des informations le plus rapidement possible. L'ingénierie de l'utilisabilité de Nielsen suggère que 10 secondes est la limite pour maintenir l'attention d'un utilisateur. Fournir de manière fiable des sites web rapides devenait de plus en plus difficile pour plusieurs raisons - et la plus importante était une technologie ancienne.

À titre d'exemple, des estimations approximatives ont montré que dans certains cas, le site Web de Jagex prenait plus de 20 secondes à charger sur une connexion 3G standard depuis un utilisateur en Californie, États-Unis. Des recherches ont montré que pour chaque seconde que votre site mobile met à se charger, les conversions chutent de jusqu'à 20%! Quelque chose devait changer.

Jagex.com

Jagex a été fondée en 1999 par les frères Gower - les sorciers qui ont construit tout, du moteur de jeu et du langage de script à leur propre plateforme web. L'échelle de leur architecture était impressionnante; cependant, son entretien devenait de plus en plus lourd. Même avec des améliorations comme notre transition vers Freemarker, qui nous avait éloignés du langage de modélisation propriétaire plus ancien, WebScript, il était temps pour l'équipe Web de commencer à penser à comment nous pourrions aller radicalement plus vite.

Code WebScript

Pour améliorer nos performances, nous devions repartir de zéro et envisager de nouvelles approches pour aligner notre pile technologique sur les normes de performance modernes. Les gens lancent souvent le terme 'cloud' comme solution à tous les problèmes techniques. Nous avons découvert que bien que le cloud ait l'évolutivité et potentiellement la vitesse, il ouvrait un abîme d'autres problèmes, y compris la sécurité, les coûts et la formation des développeurs.

Comme toutes les idées vraiment avant-gardistes, notre solution prendrait du temps - beaucoup de temps. Au point que ceux en dehors de l'équipe pourraient même dire que pendant de longues périodes, il semblait qu'aucun progrès n'était réalisé. La recherche de notre avenir web nous a conduits vers les trois grands fournisseurs de cloud : Google Cloud, AWS et Microsoft Azure. Nous avons également examiné diverses solutions gérées comme Heroku et Netlify avant de finalement nous décider pour AWS. Nous avions besoin d'un fournisseur de confiance avec une fonctionnalité existante et la flexibilité d'expansion lorsque l'entreprise l'exigeait, et la boîte à outils étendue offerte par AWS répondait à ces critères.

Mais l'infrastructure n'était pas le seul problème que nous devions résoudre. Pour fournir des pages web dynamiques sur notre plateforme actuelle, nous aurions besoin de développeurs connaissant Java, Freemarker, CSS et JS pour fournir une page adaptée aux utilisateurs finaux. Cela nécessitait souvent deux développeurs (frontend et backend) par page, ce qui ralentissait souvent la vitesse de nos projets.

Alors comment pourrions-nous résoudre cela ? Que se passerait-il si nous pouvions utiliser un seul langage pour le backend, la modélisation et le comportement frontend ? Eh bien, nous avons plongé dans le monde de JavaScript comme langage backend (effectuant la logique avant même de commencer à dessiner la page). Nous pouvions sentir tous les développeurs backend frémir même en suggérant une telle chose - la réputation de JavaScript peut-être injustement la précède. La vérité est que c'est comme la plupart des langages - utilisez-le de manière créative mais correctement et vous pouvez accomplir des tâches incroyables avec - mais avec un grand pouvoir vient une grande responsabilité. Nous devions être confiants dans la qualité de notre code, et pour faciliter cela, nous avons choisi d'utiliser TypeScript. Dans TypeScript, toutes nos variables et fonctions ont un typage strict, ce qui empêche ces problèmes JavaScript paresseux d'apparaître.

Nous avons également implémenté EJS comme langage de modélisation au lieu de Freemarker. Cela signifiait que la logique backend et de modélisation utilisait des méthodes JavaScript. Par conséquent, nous pouvions réduire la dépendance des développeurs devant connaître différents langages.

Enfin, nous avons implémenté SCSS avec la dernière version de Zurb Foundation pour gérer la cosmétique des pages afin de nous permettre de produire des mises en page compliquées avec un CSS réutilisable et organisé. Un cadre d'application web Node.js assemble ensuite le tout pour servir nos pages web au monde.

Pour tester avec précision les performances de notre nouvelle implémentation, nous avons choisi un petit site à utiliser comme référence. Le site web de l'entreprise était le candidat parfait et nous a permis de comparer les performances avec notre ancien système sans affecter l'accès au jeu.

Nos résultats étaient très encourageants car nous avons réduit de plus de 40% notre temps de chargement total. La nouvelle plateforme fonctionnait, mais nous avions besoin d'un CMS derrière elle pour permettre à d'autres employés de pouvoir changer le contenu de la page sans avoir besoin d'un développeur.

Le CMS sur lequel nous avons finalement opté était le puissant Contentful. La puissance et la polyvalence de ce CMS nous ont permis de modifier rapidement le contenu des pages tout en maintenant la flexibilité. Avec tout cela réuni, nous avons baptisé le projet Merlin - l'avenir des services technologiques de Jagex.

Vous lisez en fait l'un des premiers articles de blog servis par la plateforme Merlin, avec le reste de Jagex.com et RuneFest.com. Peu après cela, nous avons également commencé à transférer RuneScape.com sur la nouvelle plateforme avec le World Out of Time mini-site.

Mini-site World Out of Time

L'avenir de notre pile technologique semble s'annoncer de plus en plus brillant alors que nous progressons à travers 2019 avec plus de connaissances et de compréhension que jamais auparavant. Nous faisons de grands pas mais posons nos pieds sur un sol solide.

Souhaitez-vous vous joindre à nous pour façonner l'avenir de la technologie de Jagex ? Rendez-vous sur la page carrières pour les offres actuelles et aidez-nous à réformer la façon dont nous livrons le contenu.