3x Performance Improvement for Emerging Dynamics New Website [Case Study]

Sometimes the stack you use doesn’t live up to the expectations. In those cases, you either salvage what you can or opt out for a completely different option. The problems we faced while working on the EMDYN project resulted in a complete change of the stack.

It also resulted in huge performance improvements.

Before:

After:

From 5.7s to 1.2s for First Contentful Paint (the time at which the first text or image is painted) with Speed Index from 6.7s to 2.5s ie that’s how quickly the content of a page is visibly populated.

Not a bad improvement, right. So how did we do that?

The Overview

Emerging Dynamics (EMDYN) is a privately held security company, expert in intelligence-led security solutions. They help numerous multi-billion-dollar international corporations get ahead of the threat curve with state-of-the-art technology, enabling them to optimize critical decision-making and protect their assets. As such, they had two main concerns performance and security, and a simple request to move the front-end of the website to Gatsby.

Luckily for us, they were already deep into static site generators and headless CMSs which, to be honest, made our communication much easier. They have been using a flat-file cms Grav CMS but had performance issues and needed us to take care of that.

What is a flat-file CMS?

A flat-file CMS is a content management system that does not require a database but rather saves its data directly into files and folders. Advantages? Well, performance, security, and cost-effectiveness. Downsides? Template limitations and, in our case, modular pages (read on for explanation).

Gatsby + GravCMS

The initial idea was to use Grav as a headless CMS and pass the content to Gatsby. Right from the start, we've encountered a problem, the lack of plugins to connect Gatsby with Grav. The only solution was to make one. So, we rolled up our sleeves and started coding. It shouldn’t be that hard, right?

Well, it turned out we were very wrong about it. Immediately with the first version of the plugin, we encountered an issue with data passing by Grav, and we realized we can't use it as a headless CMS with Gatsby, especially with the approach of modular-pages.

Modular pages / modular content is a paradigm of building pages inside CMS. Users can build a page within available components added to CMS. In this case, CMS is not used only for storing content but also for generating/modifying pages layout itself.

The Stack We Used

This basically meant we had to come up with another stack that would pretty much keep the same web dev flow and client user experience. The tech stack we used was:

• GatsbyJS as static site generator
• Storyblok as headless CMS
• Netlify for hosting.

The Biggest Challenges We’ve Had On This Project

After a discussion with the crew from Emerging Dynamics about the issue of the modular pages, we showed them the headless CMS that would work perfectly for them, Storyblok.

Storyblok and Modular-pages

With Grav CMS previously they had modular content ie users could add/edit any page with predefined components. We’ve configured Storyblok to work in the same way so that clients' experience working with previous CMS didn’t change much.

Whatmore, one of the biggest pros for Storyblok (from a user/editor point of view) is the ability to preview components inside Storyblok, not only on a website itself. Let's say your setup has 30 predefined components. It's impossible for the user to remember all of them based on their names. With Storyblok users can quickly add components - check if this one is ok if not try with another without the need to trigger a new build.

Being able to see your website on one side and have a content edit box on the other allowing you to monitor every change, in real-time, streamlined their workflow even more so.

Finally, moving content between CMSs was amazingly easy as well. All that we needed to do was to rewrite components written in .twig (twig - PHP template engine) to React components and connect it with Storyblok.

Storyblok and Gatsby

As already mentioned in the Veronym case study where we used this combo, the source plugin for Storyblok doesn't use GraphQL and the content delivery to pages/component is slightly different than with other CMSs. Because of that, we weren’t able to use one of the benefits Gatsby offers, gatsby-image a React component specially designed to work seamlessly with Gatsby’s GraphQL queries.

Since that was the case we made a plugin, gatsby-storyblok-image, which allowed us to use gatsby-image together with Storyblok outside of GraphQL. With it, the experience of using the Gatsby websites with Storyblok on a backed increased significantly.

The Results

We were pleased with the performance improvements.

We are a performance and security-driven business so we want to make sure our site visitors also experience this from the first millisecond.

Tim Van RenterghemCEO at EMDYN

There is no doubt improving page loading time with just a couple of seconds can make a massive impact on any business. It affects user experience, SEO and conversion rates. But that was not the only benefit of the stack we used here.

By sticking to their previous editor role experience with added benefits like page preview, ability to easily manipulate pages, intuitive add/remove/edit modules on any page, we simplified their editorial workflow.

Not only we helped with performance issues but we also bettered their website admin experience.

Another interesting project and another happy client.

Need help with your website performance? Let’s get in touch!

CLICK HERE to schedule a 1-on-1 talk and learn more about what we can do for you and your business.