Preconnects
Every domain used when loading a page has to be initially connected to, which takes a little time. In many cases, the browser instantly determines which domains it needs to connect to and establishes the connection immediately.
However, sometimes an important resource in a different domain is not discovered instantly. e.g. it is requested via JavaScript. Preconnects are a way to tell the browser that it will need to connect to the domain at some point and suggest that it do so sooner rather than later.
<link rel="preconnect" href="https://domain.com">
<link rel="dns-prefetch" href="https://domain.com">Note that we also use dns-prefetch, as some browsers do not support preconnect.
Page Lightning lets you easily add preconnects. Each preconnect has a set of fields:
- Enabled – Is this preconnect applied.
- Tag – A simple name for the preconnect. Ideally, stick to a-z and dashes.
- Description – Something to remind you what the preconnect is for.
- Page Type – You can optionally restrict this preconnect to a specific page type.
- Page Paths – Or restrict it to URLs that contain specific path text.
- Href – This is the URL for the domain you want to preconnect to.
- CrossOrigin – This needs to match how the resources are loaded from the domain. e.g. fonts need to be ‘anonymous’.
Some examples where a preconnect could be of value, with some suggested domains:
- Some Page Builder Widgets = https://microapps.bigcommerce.com
- BigCommerce Recaptcha = https://www.google.com + https://www.gstatic.com
- Shogun = https://analytics.getshogun.com
- Just Uno = https://cdn.jst.ai + https://my.jst.ai + https://aly.jst.ai
- Fast Simon = https://ping.fastsimon.com + https://settings.fastsimon.com
Note: if you preload a resource, you do not need to also preconnect.
Preloads
Preloading important resources that the browser doesn’t discover immediately can help speed up the page’s initial display.
Built-In Preloads
These are preloads you can just switch on:
- The Main Bundle script.
- The CSRF script is required to make API requests.
Both are important resources that are required before the page is properly displayed, but are defined in the footer, so are discovered late.
Custom Preloads
Some resources need to load as quickly as possible so that the page is usable. Preloads can be used to tell the browser from the start that a resource should be loaded early and quickly.
Like with preconnects, Page Lightning makes it easy to add them. Here are the fields they use:
- Enabled – Is this preload applied.
- Tag – A simple name for the preload. Ideally, stick to a-z and dashes.
- Description – Something to remind you what the preload is for.
- Page Type – You can optionally restrict this preconnect to a specific page type.
- Page Paths – Or restrict it to URLs that contain specific path text.
- Href – This is the URL for the resource you want to preload.
- As – This needs to match what the resource is loaded as. e.g. image.
- Fetch Priority – High means it will load at a high priority.
- Type – Optionally specify the file type. If the browser does not support the type, it will not preload it.
- Media – Optionally specify a media command to restrict when it is applied. e.g. (width <= 600px)
- CrossOrigin – This needs to match how the resource is loaded for real. e.g. fonts need to be ‘anonymous’.
You want to ensure the preload matches the resource that the page actually uses. If not, you may see a warning in the browser’s console or notice the resource loads twice in the network tab. If the Href is correct, it may be that the CrossOrigin does not match.
Example Custom Preloads
Web Fonts
Web fonts are typically referenced in a font CSS file, which can take time to load. Preloading them means the font is applied earlier, reducing the chance of the page’s layout changing (CLS). In the browser’s network tab, you can filter by fonts to see the font CSS file load, then each font that is used. Adding a preload means the fonts load alongside the CSS file.
Look at how the waterfall shows the fonts loading far earlier with preloads, while without preloads, the page is shown before the web fonts have loaded:
Sometimes the font’s CSS file is also loaded late, for example, when a widget is loaded. In those cases, it may also be beneficial to preload the CSS file.
If you change the fonts in the theme, make sure you update the preloads.
References: Optimize web fonts
Other primary images
The image loading section handles preloading common primary images, such as the product’s main image, but there are often scenarios where a custom image is front and centre. e.g. the main home page carousel image. Preloading images like that can be beneficial.
Note that this feature is not designed to cope with responsive images.
Render Blocking script
Sometimes a theme adds blocking scripts (no async or defer) to a page’s footer. The page will not display until they have loaded. Scripts in the footer are discovered late and given a lower priority, so preloading them can reduce their impact on when the page is shown.
Review the scripts directly added to a page. If they don’t have async or defer attributes, they are render-blocking. Do some research to see if they have to be render-blocking. If not, add async or defer. If so, a preload may help.
jQuery is a common render-blocking script, and it is hard to make it safe so that it does not need to render block as other scripts depend on it. Preloading can reduce its impact. We also often see multiple copies of jQuery on a page; where possible, try to reduce this to just the one.
Search Providers or Review Widgets
You want to see the results from a search provider or review widget as soon as possible, as they are highly visible content.
Often, they cause a chain of resources to load one after another. If you can identify a precise URL for any of the resources that are used, you could preload them. Otherwise, a preconnect to their alternate domains can help.
A/B Testers
You want A/B test scripts to load as fast as possible so that they don’t cause a flicker when they alter the content.
Page Builder Widget Images
The Page Builder Widgets often contain images added late and with low priority. If any of those images are at the top of the page, they can cause a bad LCP.
If you can find the exact URL for the image (it has to be exact), preloading it will help a lot.
I’d recommend using some of Bobspadger’s widgets instead of the built-in carousel and image widget, as they are designed to be fast, responsive, and stable in height.
Early Hints
Early hints are when BigCommerce sends an early response to the browser, indicating which resources it will definitely need. The browser may start loading those resources early, improving page load time. This is great for CSS files and fonts that need to be loaded quickly.
Manually adding extra early hints is limited.
- Script Manager adds early hints for scripts specified by URL
- Resources referenced by the CDN helper can specify that they should be included in early hints.
- Images can’t be in early hints.
So if you have a script that needs to be loaded quickly. Add it to the Script Manager as a URL if you can.