Sometimes the stack you use don’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 EMDYN project resulted in a complete change of the stack.
It also resulted in huge performance improvements.
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?
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 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.
A flat file CMS is a content management system that does not require a database but rather saves its data directly into files and folder. Advantages? Well, performance, security, and cost-effectiveness. Downsides? Template limitations and, in our case, modular-pages (read on for explanation).
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. User 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.
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.
Sign up for our JAMstack newsletter!
Join the newsletter today and receive valuable, in-depth JAMstack tips, tricks, and case studies.
After a discussion with crew from Emerging Dynamics about the modular-pages issue, we showed them headless CMS that would work perfectly for them, Storyblok.
With Grav CMS previously they had modular-content ie user 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 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 user to remember all of them based on their names. With Storyblok user can quickly add component - check if this one is ok if not try with another without need to trigger new build.
Being able to see your website on one side side and have 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.
As already mentioned in Veronym case study where we used this combo, 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.
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 1-on-1 talk and learn more about what we can do for you and your business.