Case Study: Code Splitting Performance Improvement

Code Splitting is a topic our product team has worked on to improve the lighthouse score / web vitals for partners and customers. Here are some before and after statistics to show how we improved the CMPs overall performance and speed - and for the ones interested in how exactly we did it, there’s a full section on all the details.

Some of the highlights of our performance improvements:

After code splitting Default CMP: scripting takes only 1608 ms (30% reduction in time)
After code splitting CCPA: scripting takes only 1615 ms (30% reduction in time)
Privacy button splitting: We reduced the loading time to only 5 ms and the scripting time to 799ms.
We can also see the rendering, painting and system time are much faster. → Results in 64% reduction in time - which means we are 2.8 times faster.
'Dont show privacy button or CMP - Splitting use case: Overall the we have a 66% reduction in time, which means we are 2.9 times faster.
TCF: scripting takes 2152 ms (6% reduction in time)

Important info: All tests were done in testing environments - which means anything can change.
We will be doing proper/official tests again after full release.

If you want to know more and figure out exactly what we did to improve the CMPs performance, keep on reading.

Procedure & performance analysis - step by step

With all the variants inside the same code base, we're shipping more code than necessary for the CMP. We need to implement code splitting to ship only the necessary based on the variant (TCF, CCPA, Default UI).

SDK bundle size before code splitting:

The first generated file has the iife format. This format (Immediately Invoked Function Expression) wraps the code so that it can be consumed via a script tag in the browser while avoiding unwanted interactions with other code.

The second generated file has a cjs format. CJS is short for CommonJS. This format is suitable for Node and other bundlers.

The bundle has 175.82 KB (41.85 KB gzipped) and it is used for all variants. It doesn’t matter if we show the default UI, TCF or CCPA, the user will load everything.

SDK bundle size after code splitting:

The format was changed to be es, which is supported by our current module bundler (Rollup). This format is suitable for other bundlers and inclusion as a <script type=module> tag in modern browsers.

Initial bundle size: 91.766 KB (24.658 KB gzipped)

Default variant will load only the initial bundle, which means 91.766 KB (24.658 KB gzipped);
CCPA will load the initial bundle plus 2.54 KB (1.24 KB gzipped). Total: 94.306 KB (25.898 KB gzipped)
TCF will load the initial bundle plus 82.87 KB (17.6 KB gzipped). Total: 174.636 KB (42.258 KB gzipped)

We were able to drastically reduce the bundle size for the Default (48% reduction) and CCPA variant (47%). TCF variant will remain the same.

UI Performance gain

When we use the SDK with the code splitting on our UI, we can compare run performance checks and compare with the UI without the splitting.

Before code splitting

The yellow bar corresponds to the scripting and it takes 2281 ms to run and it doesn’t matter if it is the default CMP, CCPA or TCF.

After code splitting

Default CMP: scripting takes only 1608 ms (30% reduction in time)

CCPA: scripting takes only 1615 ms (30% reduction in time)

TCF: scripting takes 2152 ms (6% reduction in time)

Privacy button splitting

Regardless if the variant is TCF, CCPA or Default UI, we can still show the privacy button if this option is enabled on the admin and all consents were accepted. For the privacy button, we don’t need to load the variant specific bundle and we don’t need to load data for the services (Aggregator).

We currently have the following result when running a performance analysis.

This means we need 28ms to load data (settings and aggregator) and 1466ms to process the scripts, with a total of 2907ms.

After our performance improvements:

We reduced the loading time to only 5ms and the scripting time to 799ms. We can also see the rendering, painting and system time are much faster. Results in 64% reduction in time - which means we are 2.8 times faster.

Dont show privacy button or CMP - Splitting use case

The same logic applies to the case when we won’t show the privacy button. But we need to load even less code.

We currently have the following result when running a performance analysis.

After our performance improvements:

The big reduction was on the scripting time, from 979ms to 201ms. Overall the we have a 66% reduction in time, which means we are 2.9 times faster.

In both cases, we won’t make a call to the aggregator service when there is no need to display service details. Which will reduce the load on the service.