![]() The test pages were hosted on Github, Cloudfront, and AWS (using h2o as a server), and tested in Chrome and Canary, using WebPageTest in Dulles on both 3G Fast and Cable connections. I created several variants of the test page, and if you want to take a deeper look they’re all on GitHub complete with descriptions – The test case has four fonts – three weights of Montserrat, and an icon font – all weighing in at just under 100kB, which is in-line with the median size and number of requests for fonts based on HTTP Archive data there are no long running scripts that affect interactivity.doesn’t contain any third-party content.is only around 1,500 lines long - which is pretty short compared to most retailers sites.The page has (at least) a few shortcomings when compared to some of the real world pages I see: moved some blocking scripts from the foot of the page into the head element and added a script loaded with async, and another with defer attributes.removed unused glyphs to reduce fontawesome’s sizeĪdded a performance mark to record when the fonts were loaded (using ).switched from Google Fonts to self-hosted ones (containing just Latin glyphs).Rather than start from scratch I based the test case on the Electro ecommerce template from ColorLib with a few changes: To explore further I need a test case, something that approximates some of the pages retailers and other sites might have. Preloading fonts isn't the only option when it comes to reducing the 'Flash of Invisible Text', the CSS font-display property can be used to change the blocking behaviour but reducing the time it takes for the web fonts to replace the fallback font should still improve visual performance.Īlthough I'm focusing on fonts, many of the observations apply to the preload of other resource types too. Ideally we want the fonts downloaded much sooner, most likely after the render blocking elements in the head – this is the point where the browser starts adding the body contents to the DOM and where the fonts will be needed.ĭefault font loading behaviour - WebPageTest, Dulles, Chrome, 3G Fast ![]() The waterfall below shows the default behaviour with fonts discovered late and then having to compete with the images. after the styles have been downloaded and any blocking scripts in the head have been downloaded and executed too. When Should Fonts be Loaded?Īs most browsers delay rendering text until the relevant font is available, loading fonts sooner has become one of commonly suggested use cases for preload.Īnd based on my exploration of the HTTP Archive data it's the most frequently used case too.īy default fonts are loaded late as the browser only discovers them when it's building the render tree i.e. I’ve also seen some things I hadn’t quite expected in page load waterfalls so decided to dig deeper. I’ve being using preload with clients over the last few years but I have never been completely satisfied with the results. Preload also allows us to decouple download and execution, for example the Filament Group suggest using it to load CSS asynchronously Preload instructs the browser to download a resource even before it discovers it but so there may be performance gains by using using to prioritize fetching resources that are currently requested later in page load" is the seemingly simple advice Lighthouse gives.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |