3 minute read
Big improvements don't have to be hard nor take a long time to implement. It took, for example, only 17 lines of code to decrease the time to display text on Shopify.com by 50%. That saved visitors 1.2 seconds: each second matters given that 40% of users expect a website to load within two seconds and those same users will abandon a site if it takes longer than three.
Our fix took advantage of the preload working draft from World Wide Web Consortium (W3C), which tackles how front-end developers can communicate resource requirements to the browser during the initial page load process.
<link rel="preload"> (link element with keyword preload) is described as “a declarative fetch, allowing you to force the browser to make a request for a resource without blocking the document’s onload event.” The front-end developer can tell the browser to download a resource for the current page so that it loads faster. (Resource types available include images, fonts, media, and even stylesheets.) <link rel="preload"> is placed in the <head> element and the tags used on Shopify.com are shown below:
Before preload, fonts couldn’t download until the DOM and CSSOM were generated and to do that the browser needed to download the HTML and linked CSS files first in order to discover which font files to download. With preload, our front-end developers can tell the browser to download the font files needed at the same time as the CSS files. The faster the fonts download, the faster they can be rendered on screen.
Faster fonts can reduce or even eliminate the “Flash of Invisible Text (FOIT)”, where the browser paints the page with everything visible but the text. It’s undesirable browser behavior that impacts usability, especially on lower-end devices or in areas with slower network connections.
There are other potential options, but, at Shopify, we aim to reduce our dependencies on third-party libraries and avoid incorporating browser specific code for website rendering. This meant ruling out Google Font Loader, FontFaceObserver, and CSS Font Loading API, as they all required new third-party JavaScript library dependencies and complex coding strategies to deal with different browser requirements. <link rel="preload"> is a much simpler solution with no third party dependencies and works in browsers that incorporated the draft standard.
Preload’s browser availability was a positive factor too. It’s implemented in Chrome, which happens to be the browser of a majority of our users.
(Please note: The video displays a previous iteration of our homepage. The preload technique is in use on the current version)
SpeedCurve, one of our website performance testing tools, showed an immediate positive impact on loading time in synthetic tests using a Chrome desktop and cable ISP user profile. One measure often used is time-to-text-paint (or first meaningful paint), which measures the time it takes to render text on the screen. With preloading fonts, time-to-text-paint reduced by 1.2 seconds, a decrease of 50% compared to before implementing preload on Shopify.com. Preload also successfully eliminated FOIT for this user profile.
Preload is currently only available in Chrome and Opera. The other browsers are moving to implement preload. It’s in the latest technical preview release of Safari and under consideration for Edge, but there is no confirmation from Firefox yet.
Preload is now part of our shared component library and automatically available to project teams. Including and automating preload into the toolkit allows other marketing teams at Shopify to gain the performance benefit automatically inside of their applications.