I’m developing in my head a strategy for improved performance, particularly font handling.
Google Chrome has this super nifty feature where you can emulate another device (particularly mobile devices) including connections, so you can see how the site behaves. At the moment our load time on an unprimed cache is really bad for poor mobile connections, I’m talking 10s or more. I saw that for real when I used an android phone and going to suttacentral.net was a traumatically bad experience. I believe the standard to strive for is 2s maximum load time, as users tend to say ‘stuff this’ if a site takes more than 2s to load.
I am quite confident we could cut load time by 80% - or to put it another way, after 2s, be able to display the content of the site, even if not absolutely everything is loaded.
In terms of size (all sizes are gzipped) for components of the home page, it goes like this:
- HTML: 20KB - it would be smaller, but for cache optimization purposes I include all the epigraphs in the home page HTML, javascript stealthily chooses an epigraph to display. Having one and only one version of the home page (instead of a different version, one for each epigraph) really helps with cloudflare edge caching.
- CSS: 14kb. Although 80% of css is not needed for displaying the home page (which includes header and footer), 14kb is small by any standard. However it might be worthwhile inlining some of the CSS as an inline stylesheet, for example the quicker the browser sees a font-face declaration, the quicker it can start downloading the font. Important on high latency connections.
- JS: 47kb. Although not huge, our javascript assets can delay page loading by up to a second on slower mobile connections. Although javascript is ideally loaded last, in actuality, Chrome starts downloading the javascript before it starts downloading webfonts, this delays the fonts being available for however long it takes to finish downloading the javascript.
- Fonts ~400kb: The fonts in total to render the home page come to about 400kb, mostly Skolar (there are also some font variants not used on the homepage). The two most important fonts are the header fonts; Skolar sc and Hetu sc.
The load time reduction strategy would go like this:
- Divide the JS into essential and deferable. Essential is probably like 2kb.
- Divide the fonts into essential and deferable. Essential fonts are inlined into the CSS using Base64, this saves one or more requests and means the fonts are available the instant the CSS is parsed. I consider the essential fonts to be skolar sc and hetu sc, both for displaying the logo correctly, and because a FOUT from normal -> small caps is quite jarring! Skolar sc is quite large, so the inline component should be subsetted to ‘
SutaCenrl’ reducing it to ~5kb.
Deferable fonts would be loaded in the background but not delay page rendering, a fallback font would be used until the webfont is downloaded. A 500ms (or perhaps 1000ms) FOUT guard could be used for the benefit of fast connections. - The final high-powered option is to inline stuff into the HMTL. Both the JS and CSS are candidates for this (inlining as in inserting a
<style>...</style>or<script>...</script>element into the HTML, not the other sense as attributes on elements).
What happens at the moment at Jhanagrove with it’s 700ms round trip to Geosynchronous orbit with an unprimed browser cache is this:
0ms: Browser pointed at suttacentral.net.
700ms: DNS server responds with IP address, browser requests page.
1400 ms: HTML arrives, parses it and sends request for CSS and JS assets.
2100ms: CSS arrives, parses it and sends request for webfonts.
2800ms: Webfonts arrive. Page can finally be displayed.
What happens if the CSS and Fonts are inlined into the HTML, is this:
0ms: Browser pointed at suttacentral.net
700ms: DNS server responds, browser requests page.
1400ms: Everything arrives. Parses it and renders the page.
Inlining can thus easily cut load time by 50% on high latency connections. All of the big sites do inlining for this reason. Inlining is very powerful but like most very powerful things it should be used sparingly.
With quite minimal changes we could get the assets download required, down from 500kb, to about 100kb - the 80% load time reduction. I believe that is the low hanging fruit, if you went for higher hanging fruit a 90% reduction would be possible.
I believe targeting the ‘unprimed cache’ situation is important because generally about 50% of page views are from new visitors. Maybe 50% of those users are in the fast internet belt around USA/Europe, but that still leaves 25% of page views being on poor connections.
Implementing a more explicit ‘fall back font’ strategy will also go well with pure WOFFification. For example inlining quickly blows out if you have to inline more than one font type, but if we are using only WOFF, it is easy to just inline the WOFF font, end of problem.