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:
Downloading Javascript takes time.
Executing Javascript takes time.
Everything is Javascript.
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.
There are a multitude of reasons for bad website performance, but this blog post focuses on the #1 thing that causes bad performance that developers actually can affect: Javascript.
Downloading Javascript: Websites keep having more and more Javascript every year, which means that there is more Javascript to download before the user can interact with the page. This is especially problematic with slow network connections and can be a serious bottleneck.
Executing Javascript: The same problem as with downloading Javascript applies also to execution: more Javascript means more time spent executing. The lower-end the user’s device is, the bigger this problem becomes.
Javascript has a dominant role: Javascript is required for almost everything on the web for rich, interactive experiences (and is used even for pages that don’t require them). Frameworks like React, Vue and Angular run Javascript to generate and update the webpage (its HTML) which means more Javascript to download and execute. This blog post concentrates on use cases where Javascript is not (as) needed, and on the ways to maximize performance with websites that require rich interactivity.
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.
- Javascript adds interactivity and functionality to a webpage. Things like running code when a button is clicked, logging in a user, sending user to another page, changing the HTML structure or basically anything else can be done via Javascript.
- Browser: When a user enters a website, the user’s browser sends a request to a server that hosts all of the needed HTML, CSS and Javascript files for the webpage.
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.
For Javascript, the browser needs to parse and then execute it. Unlike HTML and CSS, this is not as fast and can become a major performance issue when a site has a lot of Javascript. Optimizing when Javascript is parsed and executed is important.
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
Client Side Rendering is the original way of rendering applications created with frontend Javascript frameworks. The lifecycle of a webpage that uses CSR is as follows:
- Browser downloads Javascript from the server.
- Browser executes the Javascript.
- The webpage is rendered by the web framework (e.g. React) and is interactive.
Problems with Client Side Rendering
- The browser needs to download all the Javascript for the website in order to render anything on the screen – depending on the size of the site this can take a long time depending on the internet speed of the user.
- Almost all of the Javascript needs to also be executed before anything is shown on the screen which can take a long time especially on older phones and heavy sites.
- Bad SEO – since all the Javascript needs to be executed on the client before any HTML is rendered on the site, search engine crawlers can’t crawl the page properly, which leads to bad SEO.
- Loading states – with CSR you have to also wait for external data loads after the Javascript has been executed which adds an additional load state to the page.
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 browser downloads the Javascript needed for the page from the server.
- The browser hydrates the page with the downloaded Javascript.
- 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.
- The browser renders the HTML and executes any Javascript that there is.
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.
- Faster than Server Side Rendering because all Javascript was executed at build time instead of at each request.
- 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
- Although Client Side Rendering is viable for web apps, it is very heavy. Usually a lot of Javascript needs to be downloaded and executed on the user’s machine before the app is interactive, which can take a long time with older devices. The problem also gets even worse as the size of the app grows: we can’t scale infinitely! (and the problem starts to affect even powerful devices).
- Static Site Generation is good for static content, but if we want to add interactivity to a static page, it runs into the same problems as CSR: we need to download and parse (potentially a lot of) Javascript.
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.