The future of Web at Jagex

It was a sunny day in Cambridge back in August 2017… members of the Jagex Web Team had just launched the responsive 'Create Account' pages for RuneScape and Old School. Finally, players on mobile devices would be able to create accounts through our website more easily and quickly than ever before. Our responsive framework used the best of our chosen languages to provide a slick and clean interface. We were taking advantage of Zurb Foundation 6's grid layout and the Atomic Design approach that allowed us to transform our legacy account creation flow within a fortnight.

But something was missing…

We knew the system was good, but despite our advancements and high-speed technical execution, we couldn't call it truly 'great'. In the world of modern web development, page load speed is everything and our new responsive system was still lacking speed!

Our users' time is a very limited resource. We need to get information to them as quickly as possible. Nielsen's Usability Engineering suggests that 10 seconds is the limit for keeping a user's attention. Reliably delivering fast websites was becoming increasingly challenging for several reasons – and the most prominent was old tech.

As an example, rough estimates showed that in some cases the Jagex corporate website would take over 20 seconds to load over a standard 3G connection from a user in California, USA. Research has shown that for every second it takes your mobile site to load, conversions drop by up to 20%! Something had to change.

Jagex was founded back in 1999 by the Gower brothers – the wizards who built everything from the game engine and scripting language to their own web platform. The scale of their architecture was impressive; however, maintaining it was becoming increasingly cumbersome. Even with improvements like our transition to Freemarker, which had pulled us well away from the older, proprietary templating language of WebScript, it was time for the Web Team to start thinking about how we could go radically faster.

In order to improve our performance, we needed to start afresh and consider new approaches to bring our tech stack in line with modern performance standards. People often throw around the term 'cloud' as the solution to all technical problems. We discovered that whilst the cloud had the scalability and potentially the speed it opened a chasm of other problems including security, costs and developer training.

Like all truly forward-thinking ideas our solution would take time – lots of time. So much so, that those outside the team might even say that for large periods of time it looked like no progress was made. The search for our web future took us to the big 3 cloud providers: Google Cloud, AWS and Microsoft Azure. We also reviewed various managed solutions such as Heroku and Netlify before we finally settled with AWS. We needed a trusted provider with existing functionality and flexibility to expand when the business required, and the extended toolset offered by AWS fitted the bill.

But infrastructure wasn't the only problem we needed to solve. In order to deliver dynamic web pages on our current platform we would need developers with knowledge in Java, Freemarker, CSS and JS to provide a page that was suitable for end-users. This often required two developers (front and back end) per page which often slowed down our project velocity.

So how could we resolve this? What if we could use one language to do the backend, the templating and front-end behaviour? Well, we took a trip down into the world of JavaScript as a back-end language (doing the logic before we even start to draw the page). We could feel all the back-end developers shudder even suggesting such a thing – JavaScript's reputation perhaps unfairly precedes itself. The truth is it is like most languages - use it creatively yet properly and you can do incredible tasks with it – but with great power comes great responsibility. We needed to be confident in the quality of our code and so to facilitate this we chose to use TypeScript. In TypeScript, all our variables and functions have strict typing which stops those lazy JavaScript problems from creeping in.

We also implemented EJS as a templating language instead of Freemarker. This meant that both the backend and templating logic used JavaScript methods. Therefore, we could reduce the dependency on developers needing to know different languages.

Finally, we implemented SCSS with the latest version of Zurb Foundation to handle the page cosmetics to allow us to produce complicated layouts with re-usable and organised CSS. A Node.js web application framework then puts it all together to serve our web pages to the world.

To accurately test the performance of our new implementation we chose a small site to use as a benchmark. The company website was the perfect candidate and allowed us to compare performance with our older system without affecting access to the game.

Our findings were very encouraging as we slashed over 40% off our total load time. The new platform worked but we needed a CMS behind it to allow other employees to be able to change page content without the need for a developer.

The CMS we eventually settled on was the mighty Contentful. The power and versatility of this CMS allowed us to rapidly alter page content but maintain flexibility. With all of this together we christened the project Merlin – the future of Jagex Technology Services.

You are in fact reading one of the first blog articles served from the Merlin platform along with the rest of Jagex.com and RuneFest.com. Shortly after this we also began moving RuneScape.com over to the new platform with the World Out of Time mini-site.

The future of our tech stack is looking ever brighter as we surge through 2019 with more knowledge and understanding than ever before. We're making big strides but placing our feet on solid ground.

Want to join us in shaping the future of Jagex's technology? Head to the careers page for the current openings and help us re-shape the way we deliver content.