by Doug

03/10/2018

CRO, Google Optimize

Make your site appear faster using Google Optimize

Summary

As a responsible citizen, you follow documentation to the letter. This means you probably load Optimize at the top of all pages on your site using the async hide functionality to minimise flicker. This is currently considered best practice.

ConversionWorks suggests there is a better practice that can offer better user experience and faster pages.

tl;dr

In our small scale test, we saw positive effects from a change in the implementation.  Don’t fire async hide and Optimize when you don’t need to. You site appears faster to the user. There are positive side effects that make your site stronger and your test targeting better.

Updated Implementation

As the page loads,  the content is hidden using a style and a script. When Optimize loads, it reveals the page. This is done to prevent flicker – the condition where test treatments make the page appear to change quickly after loading – a jarring user experience.

The order of scripts on the page is currently:

  1. Hide style
  2. Hide script
  3. Optimize
  4. dataLayer
  5. GTM

Move the dataLayer above the hide style, hide script, and Optimize. Insert a value in the dataLayer to flag whether or not a test is running on this page.  Wrap the Optimize scripts and style with logic to determine whether or not to execute Optimize. The new order of scripts and styles is then:

  1. dataLayer
    1. Hide style
    2. Hide script
    3. Optimize
  2. GTM

Why do this?

Improve page rendering speeds on the site when not testing pages.

Improve experiment targeting using metadata in dataLayer variables.

Prevent testing on critical pages – you may choose to not allow tests on secure payment pages.

Prevent rogue tests – ultimate control of test execution relies on the site allowing the test via the dataLayer variable.  Prevent unwanted tests from injecting JavaScript on pages without your knowledge and control

Use this as a panic button – disable all tests on the site using on dataLayer Variable.

Performance Analysis

The effects the conditional load of Optimize assets are perceived by users as a faster loading site. In reality, the site is presented faster even though there is no actual speed improvement in terms of page download.  The same assets are loaded but presented to the user faster.

To quantify the effects, Lighthouse is used to analyse page load metrics,  

Lighthouse is an open-source, automated tool for improving the quality of web pages.

You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did.

A series of twenty audits were conducted against the conversionworks.co.uk homepage.  10 with the normal Optimize asset loading script and 10 with the conditional load applied.  The audit configuration was chosen to demonstrate a best case scenario:

With the standard best practice Optimize script, the timeline of the page load can be seen below – each screenshot showing the page loading in 200ms intervals:

Contrast with the conditional Optimize load where the async hide style is not applied:

Content appears sooner – in the region of 600ms – an appreciable and noticeable difference. ConversionWorks suggests this will have a positive effect on user behaviour.

The Lighthouse metrics used in this analysis are User-centric performance metrics:

  • Time to first contentful paint
    • The time from starting the navigation to the first page pixels being shown to the user
    • This metric is important as the first paint tells the user that the page is loading
    • This answers the user’s question “Is it happening?”
  • Time to first meaningful paint
    • The time from starting the navigation to when meaningful content is presented to the user – a logo, an image, or other hero element.
    • This answers the user’s question “Is it useful?”
  • Speed Index
    • Perceptual Speed Index is a page load performance metric that shows you how quickly the contents of a page are visibly populated.
  • Time to interactive
    • The Time to Interactive (TTI) metric measures how long it takes a page to become interactive.
  • First CPU Idle
    • First CPU Idle marks the first time at which the page’s main thread is quiet enough to handle input.
    • Users can now interact with the page.

The chart below shows the percentage difference between the metrics observed for the 10 audits using the  standard Optimize implementation and the metrics observed during the ten audits using conditional Optimize:

Yes, this was a small scale test but even using a best case scenario, we can see that there is a noticeable change in the speed of rendering.  We’re not actually making the site faster but we are improving the user experience.

Comments

Leave a comment

Your email address will not be published.