Performance - Preloading and prefetching

This is an incredibly thorough guide to web font loading strategies, and their pros and cons.

If you’re looking for a specific approach, I’ve prepared some handy links that will take you to the section you need. Let’s say you want an approach that:

• is the most well rounded approach that will be good enough for most use cases: FOUT with a Class.

• is the easiest possible thing to implement: I’ve learned a lot about web fonts and at time of writing this article the current browser support is lacking for the easiest methods for effective/robust web font implementation. It is with that in mind that I will admit—if you’re looking for the easy way out already, you should consider not using web fonts. If you don’t know what web fonts are doing to improve your design, they may not be right for you. Don’t get me wrong, web fonts are great. But educate yourself on the benefit first. (In Defense of Web Fonts, The Value of a Web Font by Robin Rendle is a good start. If you have others, please leave a comment below!)

• is the best performance-oriented approach: Use one of the Critical FOFT approaches. Personally, at time of writing my preference is Critical FOFT with Data URI but will shift toward Critical FOFT with preload as browser support for preload increases.

• will work well with a large number of web fonts: If you’re web font obsessed (anything more than 4 or 5 web fonts or a total file size of more than 100KB) this one is kind of tricky. I’d first recommend trying to pare your web font usage down, but if that isn’t possible stick with a standard FOFT, or FOUT with Two Stage Render approach. Use separate FOFT approaches for each typeface (grouping of Roman, Bold, Italic, et cetera).

• will work with my existing cloud/web font hosting solution: FOFT approaches generally require self hosting, so stick with the tried and true FOUT with a Class approach.

This is an incredibly exhaustive list of performance tweaks, improvements, and best practices. Some may be outside the scope of smaller websites, but there are plenty of things for everyone.

Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s config file. Looking back now, things seem to have changed quite significantly.

Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).

So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — an overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.

Most of this post is really useful (and also hilarious), but these stand out as possibly super helpful:

So, this is what I wanted to happen:

• Start downloading the data as soon as possible (without blocking the HTML).
• Start downloading the app’s JavaScript as soon as possible (without blocking the HTML).
• When both the script and the data are downloaded, and the HTML has been parsed, run the script which will breath life into the page.

I could have done all sorts of fancy footwork in JavaScript to get this working, but I have a better solution. Well, it works, but I have a nagging feeling I’m doing something [ableist slur].

Browser experts get your magnifying glasses out…

• In the <head> I have a <link rel="preload" … > for both the JSON and and the JS (I have prefetch as well for browsers that don’t support preload yet)
• At the end of the body I load the application JS in a regular <script> tag.
• When the JS executes, it’s does a fetch() for the JSON file, and .then() kicks off the rendering of the React app.

That looks something like this.

Once any asset is on the way down, further calls to download it won’t go out to the network. The network calls look like this:

So unless I’m wrong, I see no reason to not preload everything at the top of the page.

This is really cool. This library seems to use the pointer’s trajectory to predict what you’re heading towards, and highlights the appropriate cube. I suspect this only works with pointers that can be detected as moving, like mice and styluses that have that capability, but probably does nothing useful with touch in most cases. Either way, give it a shot, it’s eerie. The most obvious use case for this is to pre-load a link if the user starts to head for it, but of course that has the side effect of possibly wasting the user’s data if they’re on a capped connection.