Why does performance matter?
Your business development team has a great idea of a new digital service for your website. Your CX team and your product development team has a clear vision on the features that are needed. But when coming to the development state, the reality suddenly gives a painful slap on your face:
The harsh result is the user steering at a blank screen for potentially several seconds, bad user experience, lost customers and lost revenue. The actual impact of the performance can be measured. Here are some examples on findings:
- Mobify found that every 100ms decrease in homepage load speed improved conversions by 1.11%.
- AutoAnything found that a 50% speed increase lead to 12% more sales.
- BBC found that for every additional second a page takes to load, 10% of users leave.
- Pinterest found that a 40% speed increase lead to 15% more sign-ups.
- Furniture Village found that a 20% speed increase led to 10% more mobile conversions and a 12% increase in mobile revenue.
An overview of how websites work and what is relevant for performance
- HTML makes up the elements that you can see on a webpage, like buttons, text, navigation bars etc.
- CSS adds styling to the HTML elements. Without CSS you wouldn’t have for example colored buttons or any advanced layouts.
For HTML and CSS, the browser’s rendering engine renders the markup onto the screen and parses the CSS and then applies styling to the elements. This is typically quite fast and cannot be optimized much; HTML is required for a website to show anything. Less HTML and CSS is better for performance than having more of them, though.
Ways of generating and rendering a web page
There are several options for rendering a web page
- Client Side Rendering
- Server Side Rendering
- Static Site Generation
- Incremental Static Regeneration
Client Side Rendering – Best to sites with lot of interactivity
- The webpage is rendered by the web framework (e.g. React) and is interactive.
Problems with Client Side Rendering
Server Side Rendering – Improved load times & SEO
Server side rendering differs from Client Side Rendering in multiple ways, the biggest difference in where the page is actually being rendered into HTML by the web framework. The lifecycle of a webpage that uses SSR is as follows:
- Browser requests the webpage from the server.
- The server renders the site into HTML and sends the HTML.
- The browser renders the HTML, but the page is not yet interactive.
- The webpage is now interactive.
Comparing SSR to Client Side Rendering
- Good SEO – since the server sends rendered HTML when the webpage is requested, search engines can crawl the website.
- Improved load time – the user can see the rendered webpage almost instantly, although it’s not interactive immediately.
- The time when the website is rendered but not interactive could be seen as a disadvantage. It could, for example, lead to user confusion when they click on a button and nothing happens.
- Server side rendering requires more processing power from the servers, but hosting for Server Side Rendering is nowadays very affordable
- Not the best option for simple websites.
Static Site Generation- Intended for mostly static content
Static Site Generation is similar to Server Side Rendering, the big difference being where the site generation happens. The lifecycle of a webpage that uses Static Site Generation is as follows:
- The server renders the webpage when it builds the website.
- The browser requests the webpage from the server.
- The server sends the already rendered page to the client.
Comparing SSG to Server Side Rendering
- Mostly meant for static content – since the pages are generated at build time it doesn’t make sense to use Static Site Generation for content that changes often, as a rebuild of the site would be needed, although this can be remedied with Incremental Static Regeneration, introduced in the next chapter.
- Pages can be easily cached using a CDN (content delivery network).
- Decreases server load due to only static files being served.
Incremental Static Regeneration – the “better”version of Static Site Generation
Incremental Static Regeneration is identical to Static Site Generation from the point of view of the browser; the request cycle is the exact same. The difference is how the website is generated.
Comparing ISR to Static Site Generation
- With Incremental Static Regeneration, you can still generate the website on build, but you can also regenerate individual pages on command, for example when data from a CMS, Content Management System, changes.
- This makes it possible to use Static Site Generation on very large websites with frequently changing data as the whole website doesn’t need to be rebuilt when data for some pages change.
- Means also that the page where the data changed is updated pretty much instantly.
Conclusion of rendering types
When to use Client Side Rendering (CSR), Server Side Rendering (SSR), Static Site Generation (SSG) and Incremental Static Regeneration (ISR)?
- Client Side Rendering: A viable option for web apps that have a lot of interactivity and functionality. For any other options, consider using other rendering methods.
- Server Side Rendering: Used when there is frequently changing data.
- Static Site Generation: For static pages, like a marketing page or a homepage.
- Incremental Static Regeneration: Used with Static Site Generation on individual pages that need to be regenerated whenever data from a CMS (or similar) changes.
We still might have problems for some use cases
Rendering performance should be an important factor on any website. Our experience with developing very different types of websites, digital platforms and eCommerce solutions during the years helps us to build the best optimal performance to our customers, considering the business development development targets, the nature of the webpages and the existing architecture. Our target state is to increase the amount of visitors, sign-ups, conversion rate and revenue generated on your website.