How We Built a World-First Rendering Solution for OFX

To improve site scalability and search engine discoverability, we set out to rebuild OFX’s user interface—but existing solutions didn’t fit their business needs. Here’s how one XWP developer’s intuition led to a brand new solution, empowering more people than ever before to harness the power of server-side rendering for React elements.

Background

What is OFX?

OFX is an Australian fintech company servicing SMEs, eCommerce retailers, and high-net-worth individuals. As a leader in the payments space, they’ve processed in excess of $150bn AUD in transfers from their eight regional offices spread across EMEA, APAC, and the Americas.

The Existing Sitecore Setup

Before our collaboration, each regional office had its own Sitecore-powered website, and content updates were individually uploaded to each one by a central web team. 

While the majority of updates share the bulk of the content, small edits had to be made to account for things that differ between regions (such as financial advice disclaimers) and localize their SEO efforts. This, however, had made publishing a laborious and time-consuming task, with a high risk of error.

After a thorough discovery process, we had the outline of a solution. We were going to migrate OFX from Sitecore to WordPress, centralize their publishing system, and create a system for generating common content at speed (programmatically).

This article focuses on one part of this extensive statement of work: Rebuilding the OFX user interface using React elements, and finding a way to render them on the server side.

Delivering Something Truly Incredible

As we’ll come to find out, the path to success is not always straightforward. This is where the power of working with a mastery-based agency like XWP comes into play.

Rather than delivering on the first solution that was suggested (that would cause additional complexity for OFX down the line), our team dug deep into the root of the issue, eventually creating a system that would solve a seemingly impossible problem, and properly achieve their business goals.

The impact of this discovery goes far beyond this project (although OFX is pioneering the solution!) We’ve opened up new avenues of performance for anybody who can’t use conventional server-side rendering techniques.

We’re always looking for pragmatic problem solvers. Sound like you? Check out our current vacancies 

Server-side Rendering of React.js Elements

Where We Started

The existing Sitecore sites had a number of user interface elements that had been coded with a combination of legacy technologies.

Because of the technical debt involved, we suggested that the best approach to migrate those UI pieces was to rebuild them in React. This way they could be maintained more easily, they could be optimized, and they could scale in ways that the old Sitecore system couldn’t.

However, there was a caveat: Those React elements had to be pre-rendered on the server side if Google were going to be able to crawl them properly.

Why Search Engine Discoverability Was So Important

We had set out to build a system where OFX could generate multiple localized pages from a single source, where content variations (for example, mandatory financial disclaimers unique to a specific region) are set directly from the ‘parent article’. 

This would ensure that only the most relevant information is displayed depending on the site you accessed— but Google also needed to be able to crawl that data so that they could rank based on localization.

After beginning to implement server-side rendering using the tried-and-tested solutions, however, we hit a barrier.

For performance-driven hosting providers like OFX’s, the code they host has to comply with a number of internal guidelines. This is important because it enables them to perform server-side performance optimizations that have a significant effect on user experience—but it also meant that, in this case, they couldn’t support the more common approach to server-side rendering of UI components.

But all was not lost. OFX had chosen to work with one of our long-term partners: Pantheon.

Having collaborated with the Pantheon team for a number of years, we knew they shared our passion for performance, and we were confident that they would help us in our mission to find the best possible solution for OFX.

We worked with their team to understand the deepest intricacies of their hosting environment and look for how we might proceed—with both sides bringing some fantastic ideas to the table, and a whole library of knowledge being shared.

We still needed something that did not yet exist, but we were better equipped to tackle the problem.

Stuck Between a Rock and a Hard Place. 

So, let’s take stock. At this point, there were seemingly only two options: 

• Rebuild the user interface elements using the legacy technologies that we got away from. This would take more time, would be harder to maintain, harder to scale, and would undo a lot of progress.

• Ask OFX to buy a new completely external server. We would then send requests externally to that server, and it would give us a response with server-side rendered information. But this would be an extra thing to maintain, an extra expense, and add to the complexity of future updates.

A lot of work had been done to make these components exist in React; we didn’t want to undo it all, but discoverability by search engines is a critical aspect of OFX’s business.

Thinking Outside the Box

Our Senior Engineer Dugi Surdulli loves a challenge. Although we were seemingly at a technological impasse, his intuition told him that there was something out there that would allow us to achieve OFX’s goals.

Dugi found the first doorway of opportunity in the ability to securely run executable files in Pantheon’s hosting environment. This flexibility meant that he was able to search for packages that might form the basis of a further solution.

That’s when he found a package called Vercel/PKG by Mercer, the creators of Nuxt.js (A framework that uses React.js with tons of server-side rendering built-in).

Building out a Solution

With his discovery of Vercel/PKG, Dugi had a breakthrough. By packaging Node.js and React.js servers inside an executable, he found a way to enable server-side processing within the constraints of OFX’s hosting provider.

Let’s say we want to render an interactive UI component. Dugi created an executable that ingests both the component’s front-end code and associated API requests, then renders it within the executable as a server-side ‘skeleton’ with all the necessary data.

This executable is configured to run in the background any time a page’s dynamic content changes, so its server-side output is always up to date.

While this approach satisfied requirements for search engine discoverability, it didn’t generate code that could be rendered by a web browser. For that, Dugi configured React.js to take the output of the server-side skeleton and quickly recompose it on the front end as the page loads. Because all page markup was generated during the server-side rendering process, no additional requests are made at load. 

This means front-end performance remains fast.

In the end, the user experience is seamless. The page content a visitor sees in their search results is fully aligned with what they see when they arrive on site.

Testing Our New Solution

We then took the solution to Pantheon to ensure that it wasn’t going to cause any peculiar problems with their infrastructure. 

“We had the call, Dugi explained to them what he just explained to us. And their minds were summarily blown. They had never heard of anybody doing this before.” — Duncan Schouten, Lead Product Owner 

They were amazed by the idea. They had multiple people check from a technical perspective to ensure it wasn’t going to pose any risk, and no one could find any issues. So we moved ahead.

Dugi assembled a proof of concept and shared the code, which Pantheon’s security team then reviewed. They couldn’t find anything that would cause any obvious problems on their end, so we eagerly rolled it out… 

And it worked. We had successfully found a way to server-side render React elements in a way that does not require any of the traditional approaches for doing this and can, in fact, be a self-contained system.

But perhaps the most exciting thing: This approach is repeatable. If another team wanted to leverage this solution in their composing process, they could—so long as their host supports executables. This only came about because of Dugi’s ingenuity in facing a challenge.

What Makes This Solution Unique: Improving Access to Server-Side Rendering

There were already several common methods for server-side rendering React elements, but if your hosting provider didn’t allow you to enact them, you were left with a difficult choice:

1. Use an alternative method for handling your UI, sacrificing the performance and discoverability advantages of working with server-side rendered React elements. 
2. Buy a new external server to handle rendering, which adds to the cost and complexity of maintaining your site.
3. Switch hosts, which can be a complicated process and could mean leaving behind other performance and security benefits—making for a net disadvantage.

Dugi’s solution is unique because it is the only method for server-side rending React elements that doesn’t require provisioning an external server, or sacrificing the benefits of their chosen hosting platform.

Performance Mindset

This entire project was performance-minded. Not only on front-end performance, but also on longevity, system performance, and system maintainability.

OFX’s legacy UI was built in such a way that it was doing what it needed to, but changing it was like unravelling a tangled thread. The performant choice was to rebuild it using modern, scalable architecture. And when obstacles made that difficult, XWP’s team of experts found an innovative solution.  

It’s down to our ambition of being a true partner to our clients— we’ll always work to solve customer problems in the best way possible, not simply deliver the first solution that might be identified.

“Find a partner who’s going to help you on that journey and not just say, ‘Yes, yes, yes.’ Sometimes you say ‘no,’ or ‘maybe’, ‘how do we do this in the best way?” 

Leo Postovoit — Head of Partnerships and Product Strategy

Learn more about how we define and approach performance in The Four Pillars of Website Performance.

Pantheon & XWP: A Truly Performant Partnership

We partner with Pantheon not only because of their lightning-fast hosting options, but because we share a common goal: to deliver end-to-end success to all who partner with us. Where one set of expertise ends, the other’s begins. Together, XWP and Pantheon make sure our clients get the best possible solution every time.

This is why our work for OFX is a clear measure of success. The ingenuity of the XWP Engineering team combined with Pantheon’s willingness to test new, left-of-field ideas and produced a solution with a truly global impact.

For XWP and Pantheon, it isn’t about ticking a box and moving on. It’s about building performance-driven solutions with the capacity to create a better web. Learn more about our partnership on The XWP Tonight Show S02E09.

Working With XWP

We will always work to understand what the core business problem is for your business and work to uncover the best possible solution. 

If we’d taken the path of less resistance, OFX would either be left with an expensive external server to maintain or a solution that didn’t properly solve their problem— neither of which fit our values or commitment to our clients.

Learn more about XWP, check out what we achieved with our other partners, or get in touch.