Spike on Site Rendering Optimisations

[anojperera]

Spike to understand how we can enhance loading and rendering of content in the CMS

[charlesons]

Current lighthouse scores are as follows:

Landing page:

[charlesons]

Cookies page:

[charlesons]

Climate and weather dashboard:

[charlesons]

The UK's climate is changing article:

[charlesons]

Articles landing page:

[charlesons]

As an indicator of the performance levels that should be achievable with Volto the following EEA page achieves good Lighthouse scores:

https://www.eea.europa.eu/ims/drought-impact-on-ecosystems-in-europe

As a guide the network requests and content sizes for the above example are:

[charlesons]

The network requests for the article The UK's climate is changing article are shown below:

Notable in the waterfall trace is that a significant amount of the overall time is spent waiting for a response from the server (the traces in green on the right).

[charlesons]

Looking in more detail at the first request we can see that the time spent waiting for server response was 985ms whereas the time spent on content download was 26.5ms. This is a ratio of over 1000:1 of server response time to content download time.

For this particular request an element of server response time may be explained by server side rendering processing, but this is less likely to be the case for some of the other long waits for the server further down the waterfall trace.

[charlesons]

A second factor in the overall time spent fetching resources is time spent while the connection for a request is stalled.

This is indicated in grey in a number of requests towards the bottom of the waterfall trace below (also for the article The UK's climate is changing).

As the browser can open up a maximum of 6 TCP connections at a time then these later requests are stalled until a connection becomes available.

A page with a large number of requests exacerbates the issue with long server waits described in the comments above.

[charlesons]

Following on from the observation above that more requests raises the likelihood of requests being stalled until a TCP connection becomes available we then looked into what the sources of multiple requests.

One known issue is the double requests for each figure block item which is addressed in issue #612

Setting the duplicate calls aside, there are still a significant number of requests for figure block content in pages which have multiple figures embedded in them. Each piece of embedded content (in this case the figures) require an API call to be made to request that content.

We carried out a simple experiment whereby we created charts inline within a page and compared to a similar sized dashboard page (Climate and Weather) from the CC v2 portal which has embedded figure blocks for each chart.

The inline charts page made a single, slightly larger request to get the whole content of the page, including all of the charts), whereas the embedded figures dashboard page made one request for each figure.

[charlesons]

Based on the above analysis we (@anojperera, @mikeAdamss, @eldeal, @StRhys and @charlesons) have discussed a plan of action to improve and optimise the site rendering:

1. Further explore the causes of long server response times by:
   • employing logging
   • experimenting with caching in NGINX or Volto
   • experimenting with higher resources for the pods in the cluster (potentially a RAM issue?)
   • check whether unnecessary SPAQRL queries are being executed on each content request.
2. Keep in mind the possibility of creating an option for inline figure blocks that would result in a single request for all charts on a given page.
3. Highlight best practice to content creators of not adding too many charts and maps to a single page.
4. Further explore possibilities for Server Side Rendering.
5. Implement a site wide properties feature which should ensure smoother loading of some key UI elements like the site title and phase banner. This will be addressed by issue #667
6. Split JS bundles where possible into smaller chunks that load only whats required. A notable library to target is Plotly.JS which aims to be improved in issue #138

Our goal is to meet performance set out in Google PageSpeed of max server response time 200ms and max page load time 1800ms