Reinventing bmj.com with a completely new approach to front-end development

Read time: 4 mins

When we first met the BMJ team, we were fairly nervous, as would anyone who has heard of The BMJ ( British Medical Journal). Luckily, technology is the great equalizer in our industry so we fell in sync quickly with their team, and, together, we decided to take on the challenging task of reinventing the front end of bmj.com.

This is the first chapter of our collaboration, within which we’ll be explaining the “why” behind this project, and discussing the architectural decisions we took to achieve this project.

A website redesign unlike any previous 

BMJ is a global healthcare knowledge provider of journals, clinical decision support, events and medical education. It is internationally renowned for its publication of The BMJ (British Medical Journal), which is currently one of the top five general medical journals in the world. You might not know this, but BMJ also publishes more than 70 journals, some of which are the most cited and influential titles in their specialty. Their products and services help clinicians to improve their everyday practice, and also informs patients and the general public.

As is the case for most publishers, a redesign is a routine operation, repeated every 3-4 years, mostly to update important assets and pages. Given BMJ has pioneered the migration to digital publishing and open access, a more substantial redesign was in order.

The last redesign bmj.com underwent mostly involved moving from one Drupal version to another. But 2020 has been the year of change for many of us, thus challenging BMJ to adopt a completely new way of working that puts the entire architecture of its publishing system into question. This brought about a completely new approach to front-end development.

Moving away from the monolithic approach

reinventing-bmj-com-3

Bmj .com is on a Drupal 7 platform, sitting on top of the JCore (Journal Core) platform used to host the scholarly journals provided by HighWire Press.

In 2014, Drupal was chosen because it had the most popular and biggest open-source community, widely used by other journals, magazines, and newspapers. It also provided the best available contributed modules so bmj .com could  support a high volume of traffic. BMJ’s responsive redesign and migration to Drupal 7 was a complex project. It involved the migration of a huge online content archive made up of almost 3 million content items, as well as more than 30 custom Drupal 6 modules that needed to be migrated to Drupal 7.

The Drupal ecosystem and its community have seen many major release iterations of late. In the last couple of years, they have also moved away from the monolithic approach towards enabling decoupling with Drupal 8.2. But when BMJ invested in the Drupal ecosystem, it was before that the understanding of decoupling front end and back end became more mainstream as an architectural web pattern. Some of the early decisions that helped BMJ innovate within Drupal ended up locking it out of the kind of innovation that they can do today.

More recently, with an increase in research paper output and a 158% rise in usage, bmj .com engineers have been exploring new ways to strengthen page performance. Constraints accepted with some of the early architecture decisions with Drupal recently meant that front end changes could not be made without some effort on the back end. Monoliths give a lot of advantages around reducing the cognitive overhead of the stack being used.

For many, if not most, small scholarly publishing organisations they remain a good choice, however BMJ was in the position of having the scale and skills available to try out some new approaches. So when the opportunity to take on a greenfield build of some pages presented itself, BMJ decided to follow its pioneering instinct to use static site generation as a strategy for site improvement.

reinventing-bmj-com-2

Testing the static site generation approach

A static website uses only static files—like HTML, CSS, JavaScript, images, and videos. It doesn’t call on servers or server-side processing. Static site generators (SSG) apply data and content to templates and generate a page view that can be readily served up to site visitors. 

The biggest difference between a static site generator and a traditional web application stack, is that, instead of waiting until a page is requested and then generating its view on demand each time, a static site generator does this in advance so that the view is ready to serve ahead of time.

Early indicators of a good decision

It is early days but initial tests are encouraging, to the satisfaction of both engineers and business stakeholders.

The main early success indicator is the page performance and the Google Lighthouse audit. Pages that previously scored below 10/100 in the audit now show results of between 85/100 and 90+/100 on most updated pages. Compared to the industry standard, it’s a great result and validates that this approach has the potential to radically improve user experiences.

The first page to be moved over to the new platform about three months ago was bmj.com/coronavirus. Since moving, there’s been a significant jump in search rankings for key terms related to coronavirus, with nearly a 100% increase in clicks from Google search through to the page. 

  • Another immediate effect isa drop in exit rates, from 47% to 39%, which is far lower than the site average (closer to 60%). 
  • There’s also an increase in usage itself, in page views and number of visitors. 
  • Overall pageviews to the page have increased 55% since moving to the new platform (compared with 30% for the homepage, which is a similar page on bmj .com containing similar content, but on the old platform).

As the team continues to update pages, incrementally, other indicators such as advertising revenue and a long-term one-off subscription revenue are expected to improve over the next few months. 

There’s also another advantage to this approach which hasn’t gone unnoticed. The developer experience has improved dramatically. The development environment now provides a setting whereby changes can be made in a matter of days rather than months. This means the team can now make up to 4-8 updates a day, providing both a better development and user experience overall.

Keep a close eye on our blog in the following weeks, as we continue to document our journey from a monolithic approach to a new architecture, using a cutting-edge tech stack.

Images via Pexels.com