CLS Mastery: The Secret Behind Viking CMS's Supercharged Speed and Seamless User Experience

Viking started as a solution to the problems I encountered as a front-end working with developers who were allowed to publish limited raw HTML to Frankly CMS. I had just joined the organization, and they had been using a tool called "Code Blocks" for publishing all sorts of homemade widgets, advertiser products, and in-house page designs. I found myself constantly chasing down CSS collisions and Javascript errors caused by multiple parties working in a shared environment that wasn't built to prevent collisions of CSS and/or Javascript.

It turns out, designers are really good at writing markup and styles that makes pretty things on the screen, but they are not good at thinking about the lifecycle of the whole product, or even considering the effects of their contribution on other designers. So often, they would add HTML/CSS/Javascript and then complain that "our" navigation, or footer, or other third-party products on the page was broken! Every single time, it was because designer's were being designers, and not thinking like front-end developers.

This was such an overwhelming, ongoing and intractable problem, that it motivated me to start building a complete CMS from the ground up to prevent this problem. The first feature I built was programmatic name-spacing of page-level CSS, using an SCSS compiler on the server, which solved the ongoing CSS-collision problem, this compiles with every page on render, so that the designers can't break anything else on the page! This also means they can focus their effort on the page at hand, and have one less thing to think about. This also means that AI generated HTML and CSS content is welcome, they can work that way if they prefer. In fact it means that even untrained designers, who know very little HTML and CSS, can just describe what they want to the AI of their choice and submit it in a single click! We didn't realize what we were building, at how groundbreaking it was at the time.

There was one more opportunity I discovered about how we bundle our CSS. One of the biggest SEO metrics and UX metrics to think about is "CLS" (Cumulative Layout Shift). That's the measure of how much movement there is on the page during the page load on the user's browser (client-side). Many of the enterprise-scale CMSs out there are doing it the worst possible way, using a SPA (single page app) like React or Next.js, where the entire contents of the visual field have to be unpacked into markup on the client-side. They do this for their own development convenience. There is actually no benefit whatsoever for a content-generation site to be a SPA, unless it is highly interactive with an authenticated user, such as Facebook, Twitter, or Reddit. IF you primarily show content, it's best to do the work on the server, and then hand out that already done work to the CDN nodes all over the world, ready to be consumer by your user. It was plain to me that the "cutting-edge" frameworks were a trap, a dead end. The only hope for SPAs was React-Redux, which managed states on both sides client-and-server, but that meant that a large state object had to be passed from server to client, increasing the initial payload size, as well as the overhead of the entire React-Redux package that also had to be executed on the client.

I committed to just rendering on the server, unless there was a genuine user-interactivity need on the client side, and we could handle those items separately. In the case of the News industry, this means forecasts, that vary by user location would be client-rendered, with only enough JS overhead to generate the content. Fast. Super fast! Some other examples of client-generated content would be elections, school closings, earthquake maps, podcast lists from third-party vendors, really anything that depends on an outside data feed.

Once that committment had been made, to avoid SPAs and render on the server a huge UX opportunity came up. I realized there is a difference between the first page view and the second page view. Consider a new, no-session-established user comes to your home page for the very first time. It's generally assumed that the CSS required to style the page would be held in a secondary resource, a tag in this case because once it loads it remains in browser cache and doesn't need to be re-requested. Unfortunately that doesn't help for the un-sessioned user. Their very first and possibly last experience of your page will be delayed in its styling while waiting for that potentially large external stylesheet to load, ours are generally under 30kbs, but I've seen some in the hundreds of kbs. This can mean a second or even two of "FUOC", or "Flash of Unstyled Content". You've seen it yourself. You go to a page, and some text loads, and some empty image tags, and then after the CSS comes in the whole page pretties itself up real fast like it wasn't dressed yet and you jumped in a surprised it. It looks real bad, and it is terrible for the CLS score.

The solution was to serve two different versions of the page, one for already sessioned users (been there before, already have the stylesheeet), and another version where the CSS content of the stylesheet is literally inlined in the initital document request.