fix(storefront): BCTHEME-991 Cornerstone performance optimizations: blocking scripts delaying DomContentLoaded.

[bc-yevhenii-buliuk]

What?

This PR improves some of the performance metrics of the Cornerstone theme.
Installing the Web Font Loader library to the project avoided an ajax request for fonts and accelerated their loading by about 100ms.
Including theme-bundle.main.js script using the defer-attribute allowed to avoid blocking DOM rendering and load the script in the background.

With these improvements, we have achieved the following indicators:
The performance on desktop was improved approximately from 83% to 93% and on mobile from 48% to 71%.

The received metrics were taken on localhost with Network (Fast 3G).

Tickets / Documentation

• ISSUES-2150
• BCTHEME-991

Screenshots

Initial Lighthouse metrics:
Desktop:

Mobile:

Metrics after font connection optimization:
Desktop:

Mobile:

Metrics after optimizing the connection of fonts and scripts:
Desktop:

Mobile:

[Tiggerito]

I'm a bit sceptical about chasing the scores. I like to focus on actual results, like faster loading fonts. I think the aim is to have the font system load early, non blocking and get those fonts loaded before the painting process happens. i.e. no font flicker.

If I understand the font code change. It's basically moving it into the CDN thus avoiding an extra connection to ajax.googleapis.com which can delay the blocking font code by 100ms.

It's also got rid of the dependency on it loading before the initialisation code, as that code is now in the bundle.

I think this means the bundle can be called async. But there is a catch. We want this to load early and fast as fonts affect the users experience, and async switches it to low priority. In the future we can add importance="high" to bump it back up, but for now the trick would be to preload and async it:

<link rel="preload" href="{{cdn 'assets/dist/theme-bundle.font.js'}}" as="script">
<script async src="{{cdn 'assets/dist/theme-bundle.font.js'}}" importance="high"></script>

This means it starts loading asap but does not block the processing of the rest of the html.

I'm not set up for proper stencil development so can't directly test this. But over the break I have been doing a lot of speed improvement test that worked. This is how I changed the font code to use the recommended async method:

<link rel="preload" href="https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js" as="script">
        <script>
            WebFontConfig = {
                        custom: {
                            families: ['Roboto', 'Volkhov', 'Source Sans Pro']
                        },
                        classes: false
                    };
        
            (function(d) {
                var wf = d.createElement('script'), s = d.scripts[0];
                wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js';
                wf.async = true;
                s.parentNode.insertBefore(wf, s);
            })(document);
        </script>

Your solution is neater and better as it removes a connection and puts the code in a nice neat bundle.

I noticed it was easy to get the font families out of sync with the actual fonts being used. Not sure if there is a way to ensure it is kept up to date?

I also experimented with preloading the actual font files:

{{!-- 
            Preload web fonts we know are used. On fast connections fonts can be the slowest bit. Does not seem to make much difference on slower connections.
            This also stops flicker.
            Not a very reliable way to do this as the real font URLs may change or the store may change what fonts they use.
            example...
        --}}
        <link rel="preload" href="https://fonts.gstatic.com/s/roboto/v29/KFOmCnqEu92Fr1Mu4mxK.woff2" as="font" type="font/woff2" crossorigin="anonymous">
        <link rel="preload" href="https://fonts.gstatic.com/s/volkhov/v12/SlGQmQieoJcKemNecTUEhQ.woff2" as="font" type="font/woff2" crossorigin="anonymous">

The issue here is we don't reliably know what their URLs are. I noticed that Shopify locally host their fonts which means they have full control over the URLs and avoid another connection delay.

There is also the related font css file that gets loaded:

{{{stylesheet '/assets/css/theme.css'}}}

Which turns into something like this:

<link href="https://fonts.googleapis.com/css?family=Roboto:400|Volkhov:400|Montserrat:500&display=swap" rel="stylesheet">

This css file contains those dynamic URLs for the fonts. Following the Shopify idea and this could be locally generated and even inlined or added to the css bundle.

The main gain now is adding the async so that the browser can get on with doing other things. Doing the preload and potentially the above refactoring of how fonts are handled would speed up font loading and cause a smoother user experience.

[Tiggerito]

On to theme-bundle.main. After some testing I came up with this solution:

{{!-- Stop theme-bundle.main.js from blocking
            Replace the theme-bundle.main.js script and stencilBootstrap script after it with this
            Needs to be after all uses of ~inject so jsContext is populated
            This supports async/defer and still works on IE
        --}}
        <script>
            !function(d){
                var done = false;
                var script=d.createElement('script');
                script.src="{{cdn 'assets/dist/theme-bundle.main.js'}}";
                script.async=true;
                script.defer=true;
                script.onload=script.onreadystatechange=function() {
                    if(!done) {
                        var readyState = script.readyState;
                        if(!readyState || readyState=='loaded' || readyState=='complete'){
                            done = true;
                            {{!-- Exported in app.js --}}
                            window.stencilBootstrap("{{page_type}}", {{jsContext}}).load();
                        }
                    }
                }
                d.head.appendChild(script);
            }(document)
        </script>

The complexity was mainly to support IE. Besides that the only difference is I async and defer. As I mentioned in my issue, defer only will block DOMContentLoaded, while also adding async means it does not. If this code does not have to run before DOMContentLoaded I suggest also adding async. It's also supported by more browsers.

I noticed that jsContext was not set until the end of the head, and there is a chance it gets modified as the page is parsed, so this script probably needs to stay in the footer. Scripts in the footer are discovered late and set to low priority. Because of that I added a preload in the head to get it to start loading early. Assuming it's an important script for display and user functionality:

{{!-- Get this loading as soon as possible --}}
        <link rel="preload" href="{{cdn 'assets/dist/theme-bundle.main.js'}}" as="script">
        {{!-- Not sure how chunking works, but you could potentially preload them
        <link rel="preload" href="{{cdn 'assets/dist/theme-bundle.chunk.1.js'}}" as="script">
        --}}

In my case I noticed it later loaded a chunk. So to speed that up I also preloaded it. Not sure exactly how chunks are done. Again, if they are required for user display or features, preloading will make the page useable faster.

[Tiggerito]

My issue mentioned other possible improvement related to other blocking and slow loading scripts like csrf-protection-header.

Over my holiday work I was thinking it is best to resolve these speed issues in small bites. Starting with the big wins. So maybe I raise separate issues for things like that?

Another area I did a lot of work in was in improving image loading. There's a pull request related to that #2147

[bc-yevhenii-buliuk]

@Tiggerito thank you for your comments, we appreciate the work you have done to improve the performance of the Cornerstone theme! We are sure that your experience and developments will really be useful, and we have already contributed some of your developments to this PR.

Unfortunately, we can't completely get rid of HTML rendering blocking by making the loading of the webfont.js library asynchronous, since we need to be 100% sure that this library will be loaded before the fonts we use are loaded.
Thanks to webfont.js, we prevent the font from flashing, so this library must be loaded first and then the fonts after it.
Also, thanks to the inclusion of the webfont.js library inside the project, we were able to reduce its loading time to 100ms, which also increases the metrics in the Lighthouse service.

We get fonts by using the handlebars expression

{{getFontsCollection}}

which generates

<link href="https://fonts.googleapis.com/css?family=Karla:400|Montserrat:400,700,500&amp;display=swap" rel="stylesheet">

for the Cornerstone(Light) theme. The webfont.js library in conjunction with fonts works correctly and prevents fonts from flashing, but there is also a suggestion from our side to the Storefront team - to change the value of the display=swap property to display=block to avoid font flashing on the weakest Internet connections (Slow 3G).

We also checked to include fonts locally in the project via the @font-face directive and used early loading of these fonts via link -> preload. On the one hand, this allowed us not to use the handlebars expressions {{getFontsCollection}} , which, like webfont.js, is an HTML rendering blocker. On the other hand, this decision would significantly complicate development and support in the future due to the large number of fonts and their font-weight. It would also make it harder for store owners to add new fonts. Also, adding fonts locally does not solve the problem of font flashing on a slow internet connection (Slow 3G).

Thank you again for your help and interest in this matter. If you have any other ideas to improve performance and other metrics, we will be glad to receive new comments and suggestions.

[Tiggerito]

Reading the docs on webfont: https://github.com/typekit/webfontloader

It looks like it avoids FOUT by applying wf-loading to the html tag. Plus they do mention blocking will mean it has to do its thing before any rendering can happen.

Testing on Chrome showed it did not block the start of loading the font css. I believe because css is a higher priority. What it does do is it blocks other scripts.

A solution would be to make sure the critical scripts preload so they are not fully blocked by webfont. At least they can load in advance.

I find webfont is typically faster than the main css bundle, so it not in the critical path to rendering. So I would suspect making it async would not cause any extra flicker. But I also think controlling the loading pattern would mean its blocking has little significance.

Here's Cornerstone 6.2.0 on slow 3G and slow CPU:

And here's my speed modified version:

You can see how it starts to load all the important resources instantly. The main css is still the render blocking resource, but by the time it has loaded we already have all the other critical resources loaded and run.

Changing webfont to blocking made no difference due to my preloads.

I suspected restructuring to enable font preloading would be too complex. That would have more of an effect as they don't start to load until First Paint (I believe rendering is required to know what fonts to load). On my slow 3G test I clearly saw the web font replacing the standard font. Maybe this is something to raise with Google Fonts.

[Tiggerito]

webfont seems to speed up the font loading. When used the fonts seem to load as soon as the font css is loaded. When not used it waits till main css and rendering. Valuable as long as the fonts listed in webfonts are correct. Any missing font will be loaded on render.

The standard async solution lowers the priority of webfont causing it to load late and have no benefit. My variation adds a preload to make it still load early.

However, async makes it more complex (less browser support) and results in no real benefit if we work around the blocking with preloads.

[bc-yevhenii-buliuk]

@Tiggerito indeed, adding a link->preload increases the script loading priority, and this approach can be applied when using the async or defer attributes in the script.
Now regarding the placement of this script..
The theme-bundle.main.js script you suggested adds it before the closing </ head > tag. What are the benefits of placing the script in the < head > tag rather than the </ body > tag?
And why did you decide to add the async attribute to this script? Thanks in advance for the answer.

[Tiggerito]

Hi @bc-yevhenii-buliuk I worked out that you could not move the real theme-bundle.main.js script to the head as it needed jsContext set up, but you could start it loading earlier with the preload. So my suggested "Stop theme-bundle.main.js from blocking" script is still at the end of the body.

A Twitter chat with a Google Chrome guy indicated that async trumps defer and you only do both because some browsers only support defer and others only support async. Loading the script via JavaScript effectively enforces it to be non blocking anyway.

More playing with webfont.js indicates the bundling should reliably cause a speed increase for it loading. However I find that it is very easy for the font families listed to not exactly match with the ones requested in the font css file. This causes fonts that are not used to be preloaded, and then the correct fonts still need to be loaded once the page is rendered.

For the example font css file you provided:

<link href="https://fonts.googleapis.com/css?family=Karla:400|Montserrat:400,700,500&amp;display=swap" rel="stylesheet">

I think the family would need to be set like this:

families: ['Karla:n4', 'Montserrat:n4,n7,n5', 'Open Sans'],

I'm presuming the store owner can change the fonts in the theme builder, which means the static font family in the bundle will most often be wrong?

[bc-yevhenii-buliuk]

@Tiggerito perhaps you have a more detailed description of the benefits of using async-attribute for our project.
Also I would be glad to take a closer look at the information the Google Chrome guy gave you. Thanks!

[Tiggerito]

Hi @bc-yevhenii-buliuk

Here's the conversation I had on Twitter:

https://twitter.com/patmeenan/status/1481416324857438208

async means the script will not block anything. It loads in the background and runs when the browser is ready. Which means it will not get in the way of anything else loading and running. Including the DCL (DOMContentLoad) event.

defer means the script will not block other scripts from loading but it will block the DCL event. defer scripts run before the DCL event.

Nothing means it blocks later scripts and the DCL event. i.e. the script has to be loaded and run before the document can be further processed.

Here's the sequence with the current Cornerstone (I removed a bunch of requests to make it clearer). Note how main.js has to load and run before the DCL event fires because it is blocking. Adding defer makes no difference.

Here's it with my modification to async it, where DCL is not blocked and fires before it loads.

It's common for other JavaScript to wait on DCL before running. Especially code that changes the look of the page, e.g. third party review systems. The delay in DCL will delay their widgets from showing.

I have a case where a third party review system is delayed so much due to a late DCL that Googlebot does not see it (you have about 5 seconds to show your stuff). The store lost its review rich snippets. This was partly due to the review system making requests after DCL adding to the delay, I've suggested to them that they do that earlier.

If it is important that the script is run before any scripts waiting on DCL, then leaving it as is would be required.

This applies to all scripts on the page, especially ones in the head, as without async or defer they will stop further processing of the page until they are loaded and run. In some cases the browsers is smart enough to preload later resources, but it can't do anything with them until previous blocking scripts are done.

CSS files are slightly different. They are render blocking which means the browser will not start to show the user anything until it has loaded and processed all known CSS files. This can delay the loading of resources that are part of the render, like images and fonts. webfonts.js is there to preload the needed fonts. I use the preload tag to get important images loaded early.

And the final benefit. It stops Lighthouse and Page Speed Insights from flagging those scripts, which means developers don't have to answer questions from store owners about it. And it may even up the score.

[Tiggerito]

I added these changes to my demo store to test the benefit of moving webfonts to the CDN, and in reality it makes no difference.

I've a fork of cornerstone now that has all my current speed mods on my demo store. The store is also using section.io to cache part of the pages in its CDN which greatly improves TTFB and the start of loading resources.

Here's the before waterfall from WebPageTest which is good at showing the cost of connections (green/orange/purple lines):

And then after I implemented the change:

You will see that it still has to wait on a connection. All we have does is reduce the number of connections made at the start of the process. Those connections are all set up in parallel, so reducing by one makes no real difference.

I find all these testing tools widely vary on the results they show, with Page Speed Insights the harshest for mobile tests. And I've found my self making changes just to get a better score or remove a warning even though I know it makes no difference in reality.

The store does well on desktop:

But mobile is still harsh. I know in the real world that my mods get LCP in the good range for over 75% of mobile users.

[bc-yevhenii-buliuk]

@Tiggerito thanks for the detailed answer and your focus on improving performance. We agree with adding the async attribute to the theme-bundle.main.js script, which is placed before the < /body >. Now it does not block DCL and can be executed independently of DCL.

As for the webfontloader library, it receives fonts from the {{getFontsCollection}} handlebar and, depending on
Page Builder settings {{getFontsCollection}} returns the appropriate set of fonts. For example, if you set Page Builder -> Theme Styles -> Global -> Body text font family -> Roboto, then {{getFontsCollection}} will load this font, and the webfontloader library will ensure that this font is rendered without flicker. Thus, the webfontloader library does not load fonts from an array, but only manages them. This confirms the screenshot with the fonts being loaded.

Thus, the webfontloader library manages the display of fonts received from the {{getFontsCollection}} handlebar. Therefore, we need to make sure that the webfontloader library is loaded before {{getFontsCollection}} passes fonts to it, and for this reason we include it synchronously and before the handlebar is connected.

I also tested the current PR on the store with connecting the webfontloader library via CDN and the current PR with connecting the webfontloader library via ajax. The test showed that their loading speed is approximately the same (782ms in CDN and 777ms in ajax) and also similar average metrics in Lighthouse (72 in CDN and 73 in ajax).
With the benefit of connecting via CDN (i.e. having the webfontloader library in the project), we see slightly faster loading, most often no warning messages from Lighthouse about rendering blocking from the library and more cleaner and visually pleasing code in the project.

[Tiggerito]

I updated the link to my fork as it was not going to the branch where my edits are.

I agree that this change is worth doing, even if it's mainly to get a point in Page Speed Insights and to remove an error.

I set up my demo store so that the webfonts script referenced all the correct fonts and sizes:

families: ['Roboto:n4', 'Volkhov:n4', 'Montserrat:n5', 'Source Sans Pro'],

I then changed one of the fonts in admin so that it no longer matched my list.

You can see that the two matching fonts loaded as soon as the fonts CSS was loaded. But the one that no longer was in the list did not load until the main CSS file was loaded.

If I drop the webfonts.js then all three load fonts load after the main CSS file.

I then fixed things up so the fonts matched, and all three loaded early again. So I do think the fonts listed are important. They have to match so webfonts.js can preload them and reduce the chance of flicker.

I don't think the order the script and CSS load is important. I've async on the script. If I throttle my browser it changes the order that they load and it still does its preloading. In this case the js file is the critical path:

I noticed that it did not preload fonts that were not specified in the CSS file. And that the theme only allows a limited amount of fonts. So I updated my list to include all the fonts I found:

families: ['Karla:n4', 'Roboto:n4', 'Volkhov:n4', 'Montserrat:n4,n5', 'Open+Sans:n4,n7', 'Source Sans Pro:n4'],

And it worked. Only the fonts specified in the fonts CSS were preloaded. So this should work no mater what fonts the store chooses via the settings.

I've only tested this on Chrome.

Both the fonts js and CSS files are small so will almost certainly load before the main CSS file and start the loading of the fonts. There is still a chance of flicker if those fonts take longer than the main CSS to load. The only extra steps I can think of is what I previously suggested. Locally host the fonts in a way that the theme can preload them and remove the need for webfonts.js and the delay caused by the time it or the fonts CSS file take to load.

[bc-yevhenii-buliuk]

@Tiggerito indeed, we must have all the necessary fonts in the "families"-array for the library to work correctly. These fonts are already in this PR in the font.js file.
I also tested connecting the webfontloader library below the {{getFontsCollection}} handlebar connection and it looks like it still works correctly. I tested it in different browsers on the localhost and on the store by generating a bundle for this.
In this case, we can include the webfontloader library asynchronously to avoid warning messages from Lighthouse about rendering blocking from the library. Thus, we will speed up the rendering process by another 130ms.
Based on the results, I made some changes to my PR. Thanks again for the optimization help!

[BC-krasnoshapka]

Great job! Good collaboration!
Looking forward to positive impact on BigCommerce shoppers and Lighthouse scores.

[Tiggerito]

I've been doing a lot of prototyping speed optimisations and published an article on it and made my changes public in a fork/branch of Cornerstone.

In relation to this I moved things around a bit.

I removed the options from the fonts.js and changed it to use a global variable (window.WebFontConfig) so that I could control what it was set to.

The base.html code ended up like this. The two important features are that I get the fonts to preload directly from getFontsCollection and I hide the page until the fonts are loaded or we reach a timeout (based on LCP of 2.5 seconds). The rerason I hide is because I've managed to remove all blocking code so the page shows as soon as the html is complete.

 {{!-- webfontloader --}}
      {{!--             
          This section is based on this pull request that moves webfont.js into the CDN saving the need to establish a new connection: https://github.com/bigcommerce/cornerstone/pull/2158/files 

          This solution has no render blocking resources, so the page can be rendered as soon as the html is loaded. This causes a problem as the fonts will most likely load after rendering causing layout shifts. My solution is to hide the page until the fonts are loaded or some time seconds has elapsed.

          The code sets both .wf-loading and .wf-loading-set-timeout from the start, with CSS to hide the page when both are set.
          Either webfontloader will remove .wf-loading when the fonts are loaded or our timeout will remove .wf-loading-set-timeout. And the page will show.
          This means the page should show as soon as the fonts are loaded and avoid layout shifts, or at the allocated timeout.

          The timeout period is designed to happen just before LCP goes from good to needs improvement (2.5 seconds). This means we will try and pass LCP over causing some small layout shifts due to fonts loading.
          This typically means Lighthouse and Page Speed Insights in mobile mode will not hide the page at all and therefore not delay LCP. While in desktop mode it will hide to reduce font based layout shifts

          If webfontloader is given a font that is not in the CSS, the .wf-loading is not removed for 5 seconds. I presume it is waiting for the expected CSS. So the families in webfontloader need to be right.
          The code extracts the families from getFontsCollection to ensure that. This is a hack. It would be better if BCs system provided the correct list. Neater if we had a new variable that lists the fonts in the correct format. getFontFamilies.  

          https://github.com/typekit/webfontloader
          https://github.com/typekit/webfontloader#custom
          https://github.com/typekit/fvd#values
      --}} 
      <script>
          !function(w,d){
              var cl=d.getElementsByTagName('html')[0].classList;
              cl.add("wf-loading"); 

              if (performance.now) {
                  var timeLeft = 2400-performance.now();
                  console.log('wf-loading-set-timeout '+timeLeft);
                  if (timeLeft > 0){
                      cl.add("wf-loading-set-timeout");
                      setTimeout(function(){cl.remove("wf-loading-set-timeout")},timeLeft);
                  }
              }

              var regex = /family=([^&]*)/gm;

              var families=regex.exec('{{ getFontsCollection }}')[1].replace(/\+/gm,' ').split('|');

              w.WebFontConfig = {
                  custom: {
                      families: families,
                      text: 'abcdefghijklmnopqrstuvwxyz!' 
                  },
                  events: false
              };
          }(window,document)
      </script>
      <style>
          .wf-loading.wf-loading-set-timeout body {
              visibility: hidden;
          }
      </style>
      {{!-- preload + script async is to make sure it still loads at a high priority but non blocking. In the future importance of high will do the same. --}}
      <link rel="preload" href="{{cdn 'assets/dist/theme-bundle.font.js'}}" crossorigin="anonymous" importance="high" as="script">
      <script async defer src="{{cdn 'assets/dist/theme-bundle.font.js'}}" crossorigin="anonymous" importance="high"></script>

A related change is that I inlined the CSS normally acquired by getFontsCollection. It stops a render blocking call and causes fonts to load even earlier. If this inlining could be done automatically it would be great. Could the theme system pull the CSS as it is built and provide a variable to insert it into the page. Say getFontsCollectionInline.

      {{!-- 
            Here we inline the file normally returned by getFontsCollection 
            This causes earlier font preloads (before webfontloader) as we have removed all render blocking, the html is parsed and the CSS is already present
            It also makes the font urls static so we can do things like preloads.
            May need periodic review to see if the contents of the getFontsCollection url change
            Will be out of sync if fonts are changed in the page builder

            Improvement would be to generate this from the url in getFontsCollection on theme or theme setting updates. Could this be built in?

            Feature: check save-data setting, if on stop all web fonts loading. This will save a lot of data for them and improve LCP scores on those devices. 
            It would be nice to have a stencil setting indicating if save_data is on so we can use handlebars to do the saving on the server side.
            network connection speed could also be used to limit resources. e.g. if 2g or less don't use web fonts.
            https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/save-data
        --}}
        {{!-- If you know what fonts will be used in advance you can preload them. But make sure this is kept up to date --}} 
        <link rel="preload" href="https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7l.woff2" as="font" type="font/woff2" crossorigin>
        <link rel="preload" href="https://fonts.gstatic.com/s/volkhov/v15/SlGQmQieoJcKemNecTUEhQ.woff2" as="font" type="font/woff2" crossorigin>
        <link rel="preload" href="https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw5aXo.woff2" as="font" type="font/woff2" crossorigin>
        <style>
            /* cyrillic-ext */
            @font-face {
                font-family: 'Montserrat';
                font-style: normal;
                font-weight: 500;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw0aXpsog.woff2) format('woff2');
                unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
            }
            /* cyrillic */
            @font-face {
                font-family: 'Montserrat';
                font-style: normal;
                font-weight: 500;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw9aXpsog.woff2) format('woff2');
                unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
            }
            /* vietnamese */
            @font-face {
                font-family: 'Montserrat';
                font-style: normal;
                font-weight: 500;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw2aXpsog.woff2) format('woff2');
                unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
            }
            /* latin-ext */
            @font-face {
                font-family: 'Montserrat';
                font-style: normal;
                font-weight: 500;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw3aXpsog.woff2) format('woff2');
                unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
            }
            /* latin */
            @font-face {
                font-family: 'Montserrat';
                font-style: normal;
                font-weight: 500;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUHjIg1_i6t8kCHKm4532VJOt5-QNFgpCtZ6Hw5aXo.woff2) format('woff2');
                unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
            }
            /* cyrillic-ext */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qNa7lqDY.woff2) format('woff2');
                unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
            }
            /* cyrillic */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qPK7lqDY.woff2) format('woff2');
                unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
            }
            /* greek-ext */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qNK7lqDY.woff2) format('woff2');
                unicode-range: U+1F00-1FFF;
            }
            /* greek */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qO67lqDY.woff2) format('woff2');
                unicode-range: U+0370-03FF;
            }
            /* vietnamese */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qN67lqDY.woff2) format('woff2');
                unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
            }
            /* latin-ext */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qNq7lqDY.woff2) format('woff2');
                unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
            }
            /* latin */
            @font-face {
                font-family: 'Source Sans Pro';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/sourcesanspro/v18/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7l.woff2) format('woff2');
                unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
            }
            /* latin */
            @font-face {
                font-family: 'Volkhov';
                font-style: normal;
                font-weight: 400;
                font-display: swap;
                src: url(https://fonts.gstatic.com/s/volkhov/v15/SlGQmQieoJcKemNecTUEhQ.woff2) format('woff2');
                unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
            }
        </style>
        {{!-- This could be done instead to stop the testing tools complain about a blocking css file. It is small so it makes little difference --}}
        {{!-- <link href="https://fonts.googleapis.com/css?family=Roboto:400|Volkhov:400|Montserrat:500&display=swap" rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'"> --}}

I've also submitted an idea in relation to skipping web fonts if the user has requested to save data or if their connection is slow.

[bc-yevhenii-buliuk]

@Tiggerito At the moment, we are not considering the possibility of inlining the styles of all the fonts used by the theme in the <head/>, which we can get thanks to a single handlebars expression. Otherwise, it would make them harder to maintain and develop in the future, and clutter up the code in the <head/> itself. Perhaps for a custom fork, your implementation would be better, but for general use, we prefer to use a concise handlebars expression.
If necessary, we may return to this issue in the future, but we appreciate the work you have done!

[yurytut1993]

Great job, @bc-yevhenii-buliuk

[Tiggerito]

That's fine. I think we need to do baby steps starting with what has the most gain.

I'd still like the list of fonts sent to the script to be more accurate.

The main css is large and render blocking. It is typically the critical path the LCP if all other things are fixed (e.g. preloading critical images). It's the biggest issue for speed after server response times.

If the page uses a font that is not in the fonts.js list, that font loads after the main css, adding to the time it takes for the page to be visually completed. The page is first painted once main css is loaded, and then the fonts change once they are loaded, causing FOUT or FOIT. That font change can also cause layout shifts and add to CLS but typically it is small enough to not cause a failing score.

If the font is in the fonts.js list it gets loaded once both the fonts.js and the font CSS have been loaded. Both those are smaller than the main css so it tends to speed up font loading and can often mean the fonts are loaded before the first paint elimination FOUT.

If the store owner changes a font in the page builder the list will be incorrect. That's why in my solution I scrape the correct fonts out of getFontsCollection.

                var regex = /family=([^&]*)/gm;

                var families=regex.exec('{{ getFontsCollection }}')[1].replace(/\+/gm,' ').split('|');

                w.WebFontConfig = {
                    custom: {
                        families: families,
                        text: 'abcdefghijklmnopqrstuvwxyz!' 
                    },
                    events: false
                };

Note that in some cases the font used is not the default weight (400). The correct weight also has to be provided in the list. For example, if Montserrat is used its weight is 500. If that is not correctly supplied the font does not get loaded until main css and we get FOUT.

One solution is to list all possible fonts. I think you do that now. But I've now discovered we have to add the correct weights. My code does that.

There is a down side to listing all fonts, but it won't affect the sites unless you want to implement my hidden page idea. If a font is listed that is not in the css file, the script waits for 5 seconds in hope the css will appear. It then gives up and indicates loading has stopped. If the list exactly matches the fonts in the css, loading stops once all the fonts are loaded. So the list has to be an exact match if we want to react when all fonts have been loaded. i.e. show the page without FOUT.

My solution for listing the fonts could be tidied up if we had a variable that directly returned the correct list. All I am doing is scraping the query parameter out of the getFontsCollection URL, turning it into an array, and changing +s to spaces.

Alternatively you could have getFontsCollection create both the fonts.js and the css link and have it pass the query parameter to both. Then fonts.js can directly build the font list in the same way I did. But then getFontsCollection would not be backward compatible. It would have to be a new one.

[Tiggerito]

I updated how I load the main js. I think this was to support async behaviour in IE. So not a critical change and it does make it more ugly.

I've also started adding crossorigin="anonymous" to scripts that allow it. That setting means JavaScript error tracking tools (like my Tag Rocket app) can report on errors from that script.

        {{!-- 
            Stop theme-bundle.main.js from blocking
            Replace the theme-bundle.main.js script and stencilBootstrap script after it with this
            Needs to be after all uses of ~inject so jsContext is populated
            This supports async and still works on IE

            I tried a way to move it into the cached head, but unfortunately it depends on head being complete and probably body being mostly done.
            It would be nice to get some of it in the cached head so it can preload the chunks (that code also requires head).
        --}}
        <script>
            !function(w,d){
                var done = false;
                var script = d.createElement('script');
                script.src = "{{cdn 'assets/dist/theme-bundle.main.js'}}";
                script.crossOrigin = "anonymous";
                script.async = true;
                script.onload = script.onreadystatechange = function () {
                    if (!done) {
                        var readyState = script.readyState;
                        if (!readyState || readyState == 'loaded' || readyState == 'complete') {
                            done = true;
                            {{!-- Exported in app.js --}}
                            w.stencilBootstrap("{{page_type}}", {{ jsContext }}).load();
                        }
                    }
                }
                d.head.appendChild(script);
            }(window,document)
        </script>