CSS Wizardry

Measuring Network Performance in Mobile Safari

Fri, 26 Feb 2021 01:41:12 +0000

So far this year, all but one of my clients have been concerned about Google’s //AN_Xml:upcoming Web Vitals //AN_Xml:update. //AN_Xml:The client who’s bucking the trend is great, not least because it’s given me //AN_Xml:something a little different to focus on—they’re more interested in how their //AN_Xml:site fares on iOS. What makes this particularly fun for me is that iOS Safari is //AN_Xml:a completely different ballgame to Chrome, and not something many people tend to //AN_Xml:focus on. So, I’m going to share with you a handful of tips to make it a little //AN_Xml:easier should you need to do the same—and you should do the same.

//AN_Xml: //AN_Xml:

Why iOS Gets Overlooked

//AN_Xml: //AN_Xml:

Google has a pretty tight grip on the tech industry: it makes by far the most //AN_Xml:popular browser with the best DevTools, and the most popular search engine, //AN_Xml:which means that web developers spend most of their time in Chrome, most of //AN_Xml:their visitors are in Chrome, and a lot of their search traffic will be coming //AN_Xml:from Google. Everything is very Google centric.

//AN_Xml: //AN_Xml:

This, of course, is exacerbated by the new Vitals announcement, whereby data //AN_Xml:from the Chrome User eXperience Report will be used to aid and influence //AN_Xml:rankings.

//AN_Xml: //AN_Xml:

In short, it’s easy to see why Safari gets left out in the cold.

//AN_Xml: //AN_Xml:

Why This Is a Problem

//AN_Xml: //AN_Xml:

The moment you don’t consider Safari, you’re turning your back on all of your //AN_Xml:iOS traffic. All of it. Every browser available on iOS is simply a wrapper //AN_Xml:around Safari. Chrome for iOS? It’s Safari with your Chrome bookmarks. Every bit //AN_Xml:of iOS traffic is Safari traffic.

//AN_Xml: //AN_Xml:

In short, it’s difficult to see why Safari gets left out in the cold.

//AN_Xml: //AN_Xml:

This isn’t Google’s fault, and I’ve long wished that Apple would let other //AN_Xml:browsers on their platform, but that doesn’t seem likely to happen any time //AN_Xml:soon. So, we’re stuck only with Safari. That we probably aren’t testing.

//AN_Xml: //AN_Xml:

Why This Isn’t a Huge Problem

//AN_Xml: //AN_Xml:

It’s worth noting that, by and large, the same page will perform better in iOS //AN_Xml:Safari than it would on Android Chrome—iPhones are generally far more //AN_Xml:powerful than their Android //AN_Xml:counterparts. Further, and by chance, iOS //AN_Xml:usage is //AN_Xml:strongly correlated with regions we generally find to have better //AN_Xml:infrastructure. This means that iOS devices tend //AN_Xml:to be faster and are found in ‘faster regions’.

//AN_Xml: //AN_Xml:

Same page, same connection speed, same locale, same release year, different devices.

//AN_Xml: //AN_Xml: //AN_Xml:

But, Can’t I Just Emulate?

//AN_Xml: //AN_Xml:

No.

//AN_Xml: //AN_Xml:

You Will Need…

//AN_Xml: //AN_Xml:

For better or worse, I’m an iPhone and Mac user, so I’m pretty well set up out //AN_Xml:of the gate. If you don’t have an iPhone, well, you’ll struggle to test an //AN_Xml:iPhone. But the additional need for a Mac will be a barrier to entry for many //AN_Xml:I’m afraid.

//AN_Xml: //AN_Xml:

But! Fear not! It’s not the end of the line for non-Mac users. Read on.

//AN_Xml: //AN_Xml:

Testing with WebPageTest

//AN_Xml: //AN_Xml:

WebPageTest is easily, by far, without a shadow of //AN_Xml:a doubt, the single most important tool when it comes to web performance. //AN_Xml:I could not do my job without it. I cannot overstate its importance. It’s vital.

//AN_Xml: //AN_Xml:

So imagine how happy I am to report that it has first-class, genuine iOS device //AN_Xml:support!

//AN_Xml: //AN_Xml:

Real iOS devices—unreal!

//AN_Xml: //AN_Xml: //AN_Xml:

This will give you a fantastically detailed //AN_Xml:waterfall—among //AN_Xml:plenty more—that you can go back and refer to time and again.

//AN_Xml: //AN_Xml:

However, there are two key caveats:

//AN_Xml: //AN_Xml:

The devices are in the US which doesn’t help if your typical customer is //AN_Xml:based in, say, the Balkans.
The data is static which isn’t necessarily a drawback until it //AN_Xml:is—DevTools allows us to work far more quickly and interactively, responding //AN_Xml:to changes and tweaks as we make them.

//AN_Xml: //AN_Xml:

Still, this is an amazing starting point for anyone wanting to begin profiling //AN_Xml:web performance on iOS. In fact, this is something that WebPageTest has improved //AN_Xml:upon and written //AN_Xml:about //AN_Xml:only a month prior to this article you’re reading right now.

//AN_Xml: //AN_Xml:

Testing in Safari’s DevTools

//AN_Xml: //AN_Xml:

What we really want to do, alongside capturing good benchmark- and more //AN_Xml:permanent data with WebPageTest, is interact with and inspect a site slightly //AN_Xml:more realtime. Thankfully, if you have a Mac and an iPhone, this is remarkably //AN_Xml:straighforward!

//AN_Xml: //AN_Xml:

Set Your iPhone up as a Development Device

//AN_Xml: //AN_Xml:

N.B. This step and its sub-step are optional, but highly recommended.

//AN_Xml: //AN_Xml:

Plug your iPhone into your Mac and fire up Xcode. Once its opened, go to //AN_Xml:Window » Devices and Simulators and look for your device in the resulting //AN_Xml:window.

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

Make sure that any option or alert that pertains to running your iPhone as //AN_Xml:a development device is enabled. Truthfully, I’ve never really had to do //AN_Xml:anything more in this view than unlock my phone and maybe restart it once or //AN_Xml:twice. As long as I see this much, I can guarantee the next step will work…

//AN_Xml: //AN_Xml:

Network Link Conditioner

//AN_Xml: //AN_Xml:

I honestly can’t even believe I’m telling you this… this is so cool. Now, in //AN_Xml:iOS’ Settings app, you should find a new Developer option.

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

In there, you should find a tool called Network Link Conditioner. This //AN_Xml:provides us with very accurate network throttling via a number of handy presets, //AN_Xml:or you can configure your own. This means that, even if you’re connected to the //AN_Xml:office wifi, you can still simulate slower (and very realistic) connection //AN_Xml:speeds.

//AN_Xml: //AN_Xml:

Enable Web Inspector

//AN_Xml: //AN_Xml:

Next, in Safari’s settings on iOS, head to Advanced and enable Web //AN_Xml:Inspector. That’s it! You’re good to go.

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

This will allow your desktop version of Safari to inspect the current tab of //AN_Xml:your iPhone’s Safari instance.

//AN_Xml: //AN_Xml:

Inspect Your Phone From Your Mac

//AN_Xml: //AN_Xml:

Now open Safari. I know, you haven’t opened it in a while, so hit //AN_Xml:⌘⎵ and type Safari. Head to Develop and look out for your //AN_Xml:device in the dropdown menu.

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

…and that’s it. That’s really it. You’re now inspecting your phone from Safari’s //AN_Xml:desktop DevTools:

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

As long as your phone stays unlocked and with the webpage in question active, //AN_Xml:you can inspect the iOS device as you would desktop. Neat!

//AN_Xml: //AN_Xml:

Of course, the whole point of this article is performance profiling, so let’s //AN_Xml:move over to the Network tab. If you’re used to Chrome’s Network tab then, //AN_Xml:well, I’m sorry.

//AN_Xml: //AN_Xml:

Regrettably, this far into the article and its screenshots, //AN_Xml:I learned that there is no longer a way to disable ServiceWorkers in Safari. //AN_Xml:This means none of the data in the screenshots is particularly interesting, but //AN_Xml:thankfully we aren’t here to profile my site.

//AN_Xml: //AN_Xml: //AN_Xml:

Here is how my actual iPhone on a throttled connection deals with my website. //AN_Xml:There are some truly fascinating differences between how Chrome and Safari work, //AN_Xml:visible even on a scale as small as this. It really helps drive home the //AN_Xml:importance of testing each platform in its own right, and explains why you can’t //AN_Xml:simply emulate an iPhone in Chrome’s DevTools.

//AN_Xml: //AN_Xml:

But! That said. Chrome’s DevTools are far, far better than Safari’s, so we might //AN_Xml:as well use that to our advantage, right?

//AN_Xml: //AN_Xml:

Export the HAR (Http ARchive) file from Safari’s Network panel and save it //AN_Xml:~~on your desktop where it will remain until you buy a new machine~~ //AN_Xml:somewhere sensible. Next, open Chrome and its own Network DevTools panel. //AN_Xml:Import the HAR file here.

//AN_Xml: //AN_Xml:

Viewing Safari’s Network data in Chrome’s superior DevTools.

//AN_Xml: //AN_Xml: //AN_Xml:

This is key: Safari captures less data than Chrome, which is a problem. Simply //AN_Xml:opening this file in Chrome’s DevTools doesn’t make the data itself better, but //AN_Xml:it does allow us to interrogate it far better. It’s basically just a far nicer //AN_Xml:workflow onto the data provided by Safari.

//AN_Xml: //AN_Xml:

If you want to know more about how best to use DevTools for performance //AN_Xml:testing, I’m running a workshop with Smashing Magazine real soon, and that will //AN_Xml:make you DevTools experts. You can still grab //AN_Xml:tickets.

//AN_Xml: //AN_Xml:

Why Bother?

//AN_Xml: //AN_Xml:

With iOS generally being faster, and Vitals being entirely Chrome centric, and //AN_Xml:most emerging economies being Android-led, it might seem redundant to test //AN_Xml:performance at all on iOS. In fact, it’s a relatively safe assumption that if //AN_Xml:you’re fast on, say, a Moto G4, you’ll be blazing fast on an iPhone. But still, //AN_Xml:given the sheer prevalence of iOS, it’s wise to be aware of what might currently //AN_Xml:be a total blind-spot.

//AN_Xml: //AN_Xml:

While it’s unlikely to become your default process, it’s important to know how //AN_Xml:to do it. And now you do.

//AN_Xml: //AN_Xml:

Still worried about Vitals? Drop me a line! There’s still a little //AN_Xml:while before the May update.

//AN_Xml:

Site-Speed Topography

Tue, 03 Nov 2020 23:04:10 +0000

A couple of years ago, my first few days on a new web performance project were //AN_Xml:always slow going. So many false starts, tedious workflows, and a complete lack //AN_Xml:of efficiency really made it difficult for me to find momentum. All through no //AN_Xml:fault of the client or the project, but through huge flaws in my own approach. //AN_Xml:In a bid to address this, I introduced a new tool into my arsenal so that //AN_Xml:I could hit the ground running much faster, and get answers to my clients much //AN_Xml:sooner.

//AN_Xml: //AN_Xml:

When first working on a new site-speed engagement, you need to work out quickly //AN_Xml:where the slowdowns, blindspots, and inefficiencies lie. Unless a client hires //AN_Xml:you to specifically improve the performance of one page, you’ll need a broad //AN_Xml:view of the whole site or application. Historically, I’d maybe look at Google //AN_Xml:Analytics—or a RUM solution if the client had one already—but this is only //AN_Xml:useful for showing me particular outliers, and not necessarily any patterns //AN_Xml:across the whole project.

//AN_Xml: //AN_Xml:

See entry 6. Google Analytics can show us individual slow pages, but //AN_Xml:doesn’t necessarily help us build a bigger picture of the site as a whole.

//AN_Xml: //AN_Xml: //AN_Xml:

Not only that, but Google Analytics, by default, only reports load times, which //AN_Xml:are now almost entirely redundant in the field of performance optimisation.

//AN_Xml: //AN_Xml:

I needed a more holistic way to visualise performance across an entire site, //AN_Xml:and—ideally—something more useful than load times.

//AN_Xml: //AN_Xml:

Identify Page Types

//AN_Xml: //AN_Xml:

Visualising a whole site is a little overkill, especially considering //AN_Xml:many sites may run to the tens of thousands of pages. Instead, what we can do //AN_Xml:for almost every site in the world is split the project into page types. These //AN_Xml:page types would also typically correspond to different templates in the //AN_Xml:codebase. For example, my site has a homepage, content pages (e.g. my about //AN_Xml:page), and article pages, like this one you’re reading right now; an //AN_Xml:ecommerce site would have a homepage, a product listings page (PLP), a product //AN_Xml:details page (PDP), and a search results page (SRP).

//AN_Xml: //AN_Xml:

By capturing and comparing the behaviour of these pages alone, we can //AN_Xml:immediately begin to build up a representative picture of the state of the whole //AN_Xml:site. And while we may not capture outliers this way, we can still audit those //AN_Xml:in isolation as a separate body of work if required.

//AN_Xml: //AN_Xml:

For the sake of the rest of the post, I’ll be auditing an anonymised ecommerce //AN_Xml:client of mine, but you’ll be able to swap out my page types for your own with //AN_Xml:ease.

//AN_Xml: //AN_Xml:

Gathering Data

//AN_Xml: //AN_Xml:

If a picture is worth a thousand words, a waterfall is worth a thousand //AN_Xml:pictures. Let’s start with the gold standard: //AN_Xml:WebPageTest.

//AN_Xml: //AN_Xml:

Any time you run a test with WebPageTest, you’ll get this table of different //AN_Xml:milestones and metrics. We’re interested in the first seven technical timings, //AN_Xml:First Byte through Total Blocking Time:

//AN_Xml: //AN_Xml:

WebPageTest offers a wealth of insight, but right now we don’t need //AN_Xml:to go any deeper than this.

//AN_Xml: //AN_Xml: //AN_Xml:

All we need to do now is grab this information for each of our pages and paste //AN_Xml:it into a spreadsheet. If you’d like a copy of the exact spreadsheet I use, you //AN_Xml:can get hold of it here.

//AN_Xml: //AN_Xml:

Note the bottom row shows me the Standard Deviation of the tests’ //AN_Xml:results. Higher variance means a less stable metric across pages.

//AN_Xml: //AN_Xml: //AN_Xml:

With this suite of numbers, I can now begin to make assessments.

//AN_Xml: //AN_Xml:

I can see from the screenshot above that TTFB is my most stable metric—no one //AN_Xml:page appears to have particularly expensive database queries or API calls on the //AN_Xml:back-end. Conversely, LCP is far more erratic, meaning that we are likely to //AN_Xml:have highly different content page to page (the metric isn’t bad, per se, it’s //AN_Xml:highly variable), and that it’s potentially not equally optimised or delivered. //AN_Xml:Everything else is a shade in between, and at this stage offers no real //AN_Xml:insights. It’s when we begin to graph the data that useful patterns emerge.

//AN_Xml: //AN_Xml:

Visualising the Data

//AN_Xml: //AN_Xml:

In a separate sheet—available at the same link as //AN_Xml:before—I’ve simply graphed the //AN_Xml:data by page type.

//AN_Xml: //AN_Xml:

N.B. CLS is the only metric not captured in //AN_Xml:seconds, thus appears plotted separately against the right Y-axis.

//AN_Xml: //AN_Xml: //AN_Xml:

It might be a good idea to open the above graph image up in a new tab and keep it //AN_Xml:handy during the rest of this post.

//AN_Xml: //AN_Xml:

The whole point of the exercise that follows is to allow me to move quickly, //AN_Xml:spotting patterns from afar, and not having to do any slow or meticulous work //AN_Xml:yet. I want to be able to form hypotheses and draw conclusions without viewing //AN_Xml:a single URL or a line of source code. That work is what comes next.

//AN_Xml: //AN_Xml:

For now, I’m usually sat with a coffee, some tunes on, and an old-school pen and //AN_Xml:paper making notes. What I’m hoping to ascertain is where I need to look first //AN_Xml:when I get into the audit proper. I want to rule out any dead ends or false //AN_Xml:starts. I want to maximise the work not done.

//AN_Xml: //AN_Xml:

Let’s dig in!

//AN_Xml: //AN_Xml:

Building the Map

//AN_Xml: //AN_Xml:

Firstly, I want to compare whole pages at a time. Immediately, I can see //AN_Xml:that the PLP is by far the worst offender. Almost all of its bars are higher //AN_Xml:than other pages. This means that I will likely end up giving it a little more //AN_Xml:attention than the others. Next, the other three pages are pretty similar with //AN_Xml:the homepage being marginally worse.

//AN_Xml: //AN_Xml:

Next, I’ll look for any individual outliers or extremities. Right away I can //AN_Xml:see that we have an outlying Largest Contentful Paint on the homepage and an //AN_Xml:outlying Cumulative Layout Shift on the search results page. With my pen and //AN_Xml:paper, I’ll make a note of investigating these specifically in my testing.

//AN_Xml: //AN_Xml:

After extremities, I’d like to actually find consistencies. Once again //AN_Xml:noting that TTFB is very consistent—as seen in the table view—I can draw the //AN_Xml:conclusion that back-end time (and whatever else might be happening in //AN_Xml:there) //AN_Xml:is uniformly consistent across each page type. This means that I likely don’t //AN_Xml:need to do any specific work on any individual pages, but also suggests that any //AN_Xml:general back-end improvements I make in area A will also be felt in locations //AN_Xml:B and C, too. But perhaps most importantly, the stability of TTFB means that //AN_Xml:all subsequent milestones are measured from a very reliable baseline—I don’t //AN_Xml:need to make any on the fly adjustments to other metrics in order to cross //AN_Xml:reference them. Put another way, if one page’s TTFB was an entire second later, //AN_Xml:I’d need to account for that second when comparing deltas between any of the //AN_Xml:bars.

//AN_Xml: //AN_Xml:

Which brings me onto the next bit: deltas. This is where you’ll find some really //AN_Xml:fascinating insights that can run surprisingly deep.

//AN_Xml: //AN_Xml:

Gaps between TTFB and First Paint can, by and large, be considered your //AN_Xml:critical path. This is basically how many render blocking resources each page //AN_Xml:has. Of course, it’s a little more complex than that, but for this exercise it’s //AN_Xml:an incredibly reliable proxy. Now here’s where it gets really interesting:

//AN_Xml: //AN_Xml:

If all of our TTFBs are pretty identical, then any erroneous FPs are //AN_Xml:indicative of a different amount of render blocking resources. Given that render //AN_Xml:blocking resources reside in the head of the document, this implies differing //AN_Xml:head tags on that page. Note that the PDP’s FP is almost a second slower than //AN_Xml:other pages? I think the PDP has something different about it. Is it simply an //AN_Xml:additional render-blocking resource or two? Or, perhaps a more extreme scenario //AN_Xml:is that it has entirely different head tags? Maybe this is an entirely //AN_Xml:different application? It’s not unheard of.

//AN_Xml: //AN_Xml:

The next thing I want to focus on is deltas between First Paint and First //AN_Xml:Contentful Paint. FP is defined as the first pixel, no matter what it is, //AN_Xml:being put on the screen. FCP, on the other hand, is the first image- or //AN_Xml:text-pixel rendered to the screen. Note that most pages share near-identical FP //AN_Xml:and FCP? This is a strong suggestion that a page is either:

//AN_Xml: //AN_Xml:

embedding its logo in the HTML or CSS rather than using an external image, //AN_Xml:or;
making use of font-display for its web fonts, or;
not using web fonts at all.

//AN_Xml: //AN_Xml:

Basically, the first- and first-contentful paints being identical tells us that //AN_Xml:some text or imagery was rendered in the very first pass. This also means that //AN_Xml:if we manage to improve FP, we’re likely to improve FCP for free!

//AN_Xml: //AN_Xml:

The PLP, however, does show a difference between the two. I’ll make a note in my //AN_Xml:pad to investigate font-loading strategies on this page (font-based issues are, //AN_Xml:in my experience, more common than image-based one, though I won’t rule it out //AN_Xml:completely).

//AN_Xml: //AN_Xml:

Now, let’s move on to gaps between First Contentful Paint and Speed //AN_Xml:Index. SI is a measure of the visual completeness of above the fold content //AN_Xml:over time. It’s a little more complex than //AN_Xml:that, but it’s //AN_Xml:basically dealing with visual progress. The larger the gap between FCP and SI, //AN_Xml:the longer the tail of visual completeness is. That is to say, you may have many //AN_Xml:different regions of content in the viewport that all render at different times, //AN_Xml:opposed to all popping in at once. This may or may not be desirable depending on //AN_Xml:how you’ve designed the ATF experience: you shouldn’t lazy-load anything ATF, //AN_Xml:but skeleton screens might negatively impact your SI despite being an ultimately //AN_Xml:better experience. Generally all I’m looking our for here are any long tails //AN_Xml:that suggest I’m under prioritising above the fold content.

//AN_Xml: //AN_Xml:

More interestingly, let’s take a look at Speed Index vs. Largest Contentful //AN_Xml:Paint. This is a little harder to explain, but for the most part, a large gap //AN_Xml:between SI and LCP suggests that your largest contentful paint was one of the //AN_Xml:last above the fold paints—there was a large region missing for a long while, //AN_Xml:and its late arrival is apparent in the large gap. On the other hand, a small //AN_Xml:gap suggests that your largest contentful paint was relatively early, but //AN_Xml:a smaller ATF paint is pushing your SI out—e.g. a late-loaded chat client, or //AN_Xml:a small cookie banner, etc. Ultimately, this gap might be telling me about how //AN_Xml:the nature of the ATF content came together: was it a single large region that //AN_Xml:painted late, or was it a long tail of smaller regions pushing metrics the other //AN_Xml:way?

//AN_Xml: //AN_Xml:

This means we can infer from the graph that a large but late-rendered region on //AN_Xml:the PLP is pulling out our Speed Index, but a high SI and low LCP on the SRP //AN_Xml:means we’re likely dealing with a long-tail rendering problem which is less //AN_Xml:associated with a large region.

//AN_Xml: //AN_Xml:

Next up, let’s look at Cumulative Layout Shift and other milestones. While //AN_Xml:CLS is a Core Web Vital, it’s not a milestone measured in timings. Instead, it //AN_Xml:focuses on layout stability, which is actually not much at all about speed. That //AN_Xml:said, we can still join some dots. It’s quite obvious to me that huge LCP on the //AN_Xml:PLP is pushing out our CLS—whatever content is late to render doesn’t have any //AN_Xml:placeholder or skeleton. However, and slightly more obscure, the high CLS on the //AN_Xml:SRP is not joined by a high LCP. This suggests two possible scenarios:

//AN_Xml: //AN_Xml:

Perhaps the search results page is loading its individual images without //AN_Xml:width or height attributes, meaning that while they aren’t part of one //AN_Xml:LCP, lots of small images are nudging the layout around. This confirms the //AN_Xml:long-tail rendering suspicion we came up with before, and is certainly a //AN_Xml:behaviour that would contribute to a high CLS.
Less likely, but remember that SI is only measuring above the fold //AN_Xml:completeness, so there’s a chance that a huge initial CLS pushed a lot of //AN_Xml:render-regions off-screen, improving the SI score in the process. However, //AN_Xml:I would expect to see this also reflected in a more severe LCP, too.

//AN_Xml: //AN_Xml:

Finally, Total Blocking Time cannot be reliably or meaningfully compared //AN_Xml:against many other metrics as other milestones (except CLS) are network-bound //AN_Xml:and TBT is CPU-bound. The only correlation one might draw would be between //AN_Xml:a large TTFB–First Paint delta and a heightened TBT metric. Remember, a large //AN_Xml:gap between TTFB and FP is indicative of more synchronous assets in the //AN_Xml:head—if TBT goes up as well, it’s more likely that those assets are JS and not //AN_Xml:CSS. More often than not, I would simply view TBT in isolation.

//AN_Xml: //AN_Xml:

Final Word

//AN_Xml: //AN_Xml:

All of this information gleaned without having to visit a single page or view //AN_Xml:a single line of source code. I didn’t need to pick through a single bit of //AN_Xml:DevTools! This is the approach I take on every new audit project so that I can //AN_Xml:quickly identify what issues might need investigation first, what liabilities //AN_Xml:might be where, and more importantly, what work I can avoid doing.

//AN_Xml: //AN_Xml:

Being able to gather this many clues so quickly sets me up incredibly well ahead //AN_Xml:of digging into the project fully; it tells me exactly where to look first. This //AN_Xml:entire exercise is a great way of knowing where to start, which was always one //AN_Xml:of the most tricky parts of the process for me.

//AN_Xml:

The Fastest Google Fonts

Tue, 19 May 2020 17:35:04 +0000

//AN_Xml: //AN_Xml:

For the most part, web fonts nowadays are faster than ever. With more //AN_Xml:standardised FOUT/FOIT behaviour from browser vendors, to the newer //AN_Xml:font-display specification, performance—and therefore the user—seems to have //AN_Xml:been finally been put front-and-centre.

//AN_Xml: //AN_Xml:

It’s widely accepted that self-hosted fonts are the fastest option: same origin //AN_Xml:means reduced network negotiation, predictable URLs mean we can preload, //AN_Xml:self-hosted means we can set our own cache-control //AN_Xml:directives, and //AN_Xml:full ownership mitigates the risks that come with leaving static assets on //AN_Xml:third-party //AN_Xml:origins.

//AN_Xml: //AN_Xml:

That said, the convenience of a service like Google Fonts cannot be overstated. //AN_Xml:Their ability to serve the tiniest possible font files tailored to specific user //AN_Xml:agents and platforms is amazing, and with such a huge, freely-available library //AN_Xml:served from Google-grade CDNs… I definitely see why people continue to turn to //AN_Xml:it.

//AN_Xml: //AN_Xml:

On this site, in which performance is the only name of the game, I forgo web //AN_Xml:fonts entirely, opting instead to make use of the visitor’s system font. This is //AN_Xml:fast, incredibly well suited to the device in question, and has almost zero //AN_Xml:engineering overhead. But, on harry.is, I really wanted to //AN_Xml:throw caution to the wind. To hell with it! Let’s have a web font!

//AN_Xml: //AN_Xml:

However, I still needed it to be fast.

//AN_Xml: //AN_Xml:

While prototyping, I turned to Google Fonts, and with their recent ability to //AN_Xml:support font-display via a URL parameter (&display=swap), I knew that things //AN_Xml:would stay pretty speedy. Then I had an idea.

//AN_Xml: //AN_Xml:

It started with a tweet:

//AN_Xml: //AN_Xml:

TIP: If you’re going to //AN_Xml:use `font-display` for your Google Fonts then it makes sense to asynchronously //AN_Xml:load the whole request chain. pic.twitter.com/k6obyVZGZP
— Harry //AN_Xml:Roberts (@csswizardry) 11 //AN_Xml:May, 2020

//AN_Xml: //AN_Xml:

While font-display: swap; is a huge win, there are still a lot of things //AN_Xml:leaving me feeling uneasy. What else could I do to make Google Fonts fast?

//AN_Xml: //AN_Xml:

Suffice to say, I ended up going down a little rabbit hole…

//AN_Xml: //AN_Xml:

Testing

//AN_Xml: //AN_Xml:

I ran the same suite of tests against the harry.is and //AN_Xml:csswizardry.com homepages. I started out with //AN_Xml:harry.is because that’s where I was using Google Fonts, but I felt it was a page //AN_Xml:too simple to be realistic. So, I cloned the CSS Wizardry homepage a bunch of //AN_Xml:times and implemented the various different methods there. For each section of //AN_Xml:this post, I will list the results for both sites. My variants are:

//AN_Xml: //AN_Xml:

Legacy: Google Fonts with no font-display.
font-display: swap;: Using Google Fonts’ new default.
Async CSS: Loading the Google Fonts File asynchronously.
preload: preloading the CSS file to increase its priority.
preconnect: Warming up the fonts.gstatic.com origin myself.

//AN_Xml: //AN_Xml:

Further, each variant is additive—it includes the previous variant as well as //AN_Xml:its own additions. I didn’t try just preload or just async, because it //AN_Xml:would be pointless—we know that a combination will fare better than any on their //AN_Xml:own.

//AN_Xml: //AN_Xml:

For each test, I captured the following metrics:

//AN_Xml: //AN_Xml:

First Paint (FP): To what extent is the critical path affected?
First Contentful Paint (FCP): How soon can we actually read something, //AN_Xml:whether it’s a web font or not?
First Web Font (FWF): At what point has the first web font loaded?
Visually Complete (VC): When has everything settled down (a proxy, but not //AN_Xml:equivalent to, Last Web Font)?
Lighthouse Score: Does it even count if it wasn’t on Lighthouse?

//AN_Xml: //AN_Xml:

N.B. All tests were conducted using a private WebPageTest instance //AN_Xml:(WebPageTest is down right now so I was unable to use the public instance, which //AN_Xml:means I can’t share any URLs—apologies). The specific profile was a Samsung //AN_Xml:Galaxy S4 over 3G.

//AN_Xml: //AN_Xml:

To make the snippets easier to read, I’m going to replace all instances of //AN_Xml:https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,400;0,700;1,400;1,700 //AN_Xml:with $CSS.

//AN_Xml: //AN_Xml:

Default/Legacy

//AN_Xml: //AN_Xml:

Google Fonts played a really great move in the last year or so. By default, any //AN_Xml:newly created Google Font snippet comes with the &display=swap parameter that //AN_Xml:injects font-display: swap; into all of the @font-face at-rules. The value //AN_Xml:of the parameter can be any of swap, optional, fallback, or block. You //AN_Xml:can read more on //AN_Xml:MDN.

//AN_Xml: //AN_Xml:

For my baseline, however, I was going to trim the font-display back off. This //AN_Xml:is the legacy format that a lot of sites will likely still use, and it makes for //AN_Xml:a more suitable baseline to compare against.

//AN_Xml: //AN_Xml:

Snippet:

//AN_Xml: //AN_Xml:

<link rel="stylesheet"
//AN_Xml:      href="$CSS" />

//AN_Xml: //AN_Xml:

There are two key issues here:

//AN_Xml: //AN_Xml:

A synchronous, ergo render-blocking, CSS file on a third-party origin.
A file containing @font-face at-rules with no font-display descriptors.

//AN_Xml: //AN_Xml:

It’s synchronous on top of synchronous—not good.

//AN_Xml: //AN_Xml:

Results (s) – harry.is:

FP	FCP	FWF	VC	Lighthouse
3.4	4.6	4.9	5.0	98

//AN_Xml: //AN_Xml:

Results (s) – CSS Wizardry:

FP	FCP	FWF	VC	Lighthouse
3.4	4.3	4.4	4.4	96

//AN_Xml: //AN_Xml:

Alright. Here’s our baseline. The Google Fonts file is the only render-blocking //AN_Xml:external resource either of the two tests has, and we can see they both have the //AN_Xml:exact same first paint. One thing I was happily surprised by during these //AN_Xml:experiments was the consistency of Google Fonts.

//AN_Xml: //AN_Xml:

At this point, Lighthouse is giving one error and one warning:

//AN_Xml: //AN_Xml:

(Error) Ensure text remains visible during webfont load
(Warning) Eliminate render-blocking resources

//AN_Xml: //AN_Xml:

The first is a result of not having a web font loading solution (e.g. //AN_Xml:font-display); the second is a result of the synchronous Google Fonts CSS //AN_Xml:file.

//AN_Xml: //AN_Xml:

Now, let’s start adding some progressive changes and, hopefully, improvements.

//AN_Xml: //AN_Xml:

`font-display: swap;`

//AN_Xml: //AN_Xml:

For this test, I added the &display=swap back in. In effect, this makes the //AN_Xml:font files themselves asynchronous—the browser immediately displays our fallback //AN_Xml:text before swapping to the web font whenever it arrives. This means we’re not //AN_Xml:going to leave users looking at any invisible text (FOIT), which makes for both //AN_Xml:a faster and more pleasant experience.

//AN_Xml: //AN_Xml:

N.B. It’s only more pleasant if you make the effort to define a suitable //AN_Xml:fallback to display in the interim—flashing a page full of Times New Roman //AN_Xml:before settling on Open Sans would likely be a net worse experience. Thankfully, //AN_Xml:Monica has made this process not only easy, //AN_Xml:but surprisingly fun. I wouldn’t be able to do this bit without her Font Style //AN_Xml:Matcher.

//AN_Xml: //AN_Xml:

Snippet:

//AN_Xml: //AN_Xml:

<link rel="stylesheet"
//AN_Xml:      href="$CSS&display=swap" />

//AN_Xml: //AN_Xml:

Results – harry.is:

	FP	FCP	FWF	VC	Lighthouse
	3.4	3.4	4.5	5.2	99
Change from Baseline:	0	−1.2	−0.4	+0.2	+1

//AN_Xml: //AN_Xml:

Results – CSS Wizardry:

	FP	FCP	FWF	VC	Lighthouse
	3.6	3.6	4.6	4.6	95
Change from Baseline:	+0.2	−0.7	+0.2	+0.2	−1

//AN_Xml: //AN_Xml:

We haven’t removed any render-blocking resources from the critical path, so //AN_Xml:I wasn’t expecting to see any improvements in first paint. In fact, while //AN_Xml:harry.is remained identical, CSS Wizardry got 200ms slower. What we do see, //AN_Xml:however, is a dramatic improvement in first contentful paint—over a second //AN_Xml:on harry.is! First web font improved on harry.is, but not on //AN_Xml:csswizardry.com. Visually complete was 200ms slower.

//AN_Xml: //AN_Xml:

I’m happy to say, for the metrics that matter the most, we are 700–1,200ms //AN_Xml:faster.

//AN_Xml: //AN_Xml:

While this does massively improve the time it takes the web font to render, it’s //AN_Xml:still defined inside a synchronous CSS file—we can only expect so much //AN_Xml:improvement from this move.

//AN_Xml: //AN_Xml:

Predictably, Lighthouse now only gives one warning:

//AN_Xml: //AN_Xml:

(Warning) Eliminate render-blocking resources

//AN_Xml: //AN_Xml:

Therefore, the next step is to solve the synchronous CSS file.

//AN_Xml: //AN_Xml:

To quote, err, myself: If you’re going to use font-display for your Google //AN_Xml:Fonts then it makes sense to asynchronously load the whole request chain. It //AN_Xml:was this initial thought that led to my tweet in the first place—if I’ve //AN_Xml:effectively made the contents of the CSS file asynchronous, then it kinda sucks //AN_Xml:to leave the CSS file itself fully synchronous.

//AN_Xml: //AN_Xml:

font-display: swap; is a good idea.

//AN_Xml: //AN_Xml:

Async CSS

//AN_Xml: //AN_Xml:

Making your CSS asynchronous is one of the key techniques involved in employing //AN_Xml:Critical CSS. While there are a number of ways to achieve this, I’d dare say the //AN_Xml:simplest and most ubiquitous is Filament Group’s print media type //AN_Xml:trick.

//AN_Xml: //AN_Xml:

This will implicitly tell the browser to load the CSS file in a non-blocking //AN_Xml:fashion, applying the styles only to the print context. However, the moment the //AN_Xml:file arrives, we tell the browser to apply it to all contexts, thus styling //AN_Xml:the rest of the page.

//AN_Xml: //AN_Xml:

Snippet:

//AN_Xml: //AN_Xml:

<link rel="stylesheet"
//AN_Xml:      href="$CSS&display=swap"
//AN_Xml:      media="print" onload="this.media='all'" />

//AN_Xml: //AN_Xml:

While the trick is devilishly simple—which is what makes it so cool—I’ve long //AN_Xml:had my reservations. Y’see, a regular, synchronous stylesheet blocks //AN_Xml:rendering, so a browser will assign it Highest priority. A print stylesheet //AN_Xml:(or any stylesheet that doesn’t match the current context) is assigned the //AN_Xml:priority at the complete opposite end of the spectrum: Idle.

//AN_Xml: //AN_Xml:

This means that as browsers begin making requests, the asynchronous CSS file //AN_Xml:often gets grossly under-prioritised (or rather, it’s prioritised correctly, but //AN_Xml:probably way less than you expect). Take for example Vitamix, a client for whom //AN_Xml:I implemented asynchronous CSS for their own font provider(s):

//AN_Xml: //AN_Xml:

While Chrome can do asynchronous DNS/TCP/TLS, it will serialise and //AN_Xml:stall non-critical requests on slower connections.

//AN_Xml: //AN_Xml: //AN_Xml:

The browser is doing exactly what we told it: request these CSS files with //AN_Xml:a print-stylesheet’s worth of priority. Thus, on a 3G connection, it takes over //AN_Xml:nine seconds to download each file. The browser puts almost everything else, //AN_Xml:including in-body resources, ahead of our print stylesheets. This means that //AN_Xml:the page in question didn’t render its custom font until an eyewatering 12.8s on //AN_Xml:3G.

//AN_Xml: //AN_Xml:

Thankfully, while dealing with web fonts, this isn’t the end of the world:

//AN_Xml: //AN_Xml:

they should always be considered an enhancement anyway, so we need to be able //AN_Xml:to cope without them;
we can and should design decent fallbacks for use during their absence, and;
if we expect delays of such severity, we should use font-display: optional;.

//AN_Xml: //AN_Xml:

For below the fold CSS, however, delays of almost 10 seconds are //AN_Xml:unacceptable—it’s almost 100% certain that a user will have scrolled within that //AN_Xml:timeframe.

//AN_Xml: //AN_Xml:

Still! What happens to Google Fonts if we load it asynchronously?

//AN_Xml: //AN_Xml:

Results – harry.is:

	FP	FCP	FWF	VC	Lighthouse
	1.8	1.8	4.5	5.1	100
Change from Baseline:	−1.6	−2.8	−0.4	+0.1	+2
Change from Previous:	−1.6	−1.6	0	−0.1	+1

//AN_Xml: //AN_Xml:

Results – CSS Wizardry:

	FP	FCP	FWF	VC	Lighthouse
	1.7	2.2	4.9	5.0	99
Change from Baseline:	−1.7	−2.1	+0.5	+0.6	+3
Change from Previous:	−1.9	−1.4	+0.3	+0.4	+4

//AN_Xml: //AN_Xml:

These results are tremendous.

//AN_Xml: //AN_Xml:

I’m really happy with these outcomes. First paint was a staggering 1.6–1.7s //AN_Xml:improvement on our baseline, and up to a 1.9s improvement on the previous //AN_Xml:variant in the case of CSS Wizardry. First contentful paint was improved as //AN_Xml:much as 2.8s against our baseline, and Lighthouse scores hit 100 for the //AN_Xml:first time.

//AN_Xml: //AN_Xml:

As far as the critical path is concerned, this was a huge win.

//AN_Xml: //AN_Xml:

However—and this is a big however—as a result of lowering the priority of the //AN_Xml:CSS file, our first web font is up to 500ms slower in the case of CSS //AN_Xml:Wizardry against our baseline. This is the danger of the print media hack.

//AN_Xml: //AN_Xml:

Asynchronously loading Google Fonts is a net good idea, but reducing the //AN_Xml:priority of the CSS file has actually slowed down the rendering of our custom //AN_Xml:font.

//AN_Xml: //AN_Xml:

I’m going to say that asynchronous CSS is an overall good idea but I need to //AN_Xml:somehow mitigate the priority issue.

//AN_Xml: //AN_Xml:

`preload`

//AN_Xml: //AN_Xml:

Okay, so if print CSS is too low priority, what we need is a high priority //AN_Xml:asynchronous fetch. Enter preload.

//AN_Xml: //AN_Xml:

Complementing our media-trick stylesheet with a preload ensures we get the //AN_Xml:best of all worlds:

//AN_Xml: //AN_Xml:

an asynchronous high priority fetch that will work in almost all modern //AN_Xml:browsers, and;
a very widely supported method for reapplying CSS that we loaded //AN_Xml:asynchronously.

//AN_Xml: //AN_Xml:

N.B. We can’t go full preload as it isn’t widely enough supported. In //AN_Xml:fact, at the time of writing, about 20% of this site’s visitors would be unable //AN_Xml:to make use of it. Consider the print stylesheet a fallback.

//AN_Xml: //AN_Xml:

Snippet:

//AN_Xml: //AN_Xml:

<link rel="preload"
//AN_Xml:      as="style"
//AN_Xml:      href="$CSS&display=swap" />
//AN_Xml:
//AN_Xml:<link rel="stylesheet"
//AN_Xml:      href="$CSS&display=swap"
//AN_Xml:      media="print" onload="this.media='all'" />

//AN_Xml: //AN_Xml:

N.B. In future, we should be able to use Priority Hints to solve this issue.

//AN_Xml: //AN_Xml:

Results – harry.is:

	FP	FCP	FWF	VC	Lighthouse
	1.8	1 .8	4.5	5.3	100
Change from Baseline:	−1.6	−2.8	−0.4	+0.3	+2
Change from Previous:	0	0	0	+0.2	0

//AN_Xml: //AN_Xml:

Results – CSS Wizardry:

	FP	FCP	FWF	VC	Lighthouse
	2.0	2.0	4.3	4.3	98
Change from Baseline	−1.4	−2.3	−0.1	−0.1	+2
Change from Previous	+0.3	−0.2	−0.6	−0.7	−1

//AN_Xml: //AN_Xml:

While first paint either remained the same or got slower, first contentful //AN_Xml:paint either remained the same or got faster, and in the case of CSS Wizardry, //AN_Xml:first web font was a staggering 600ms faster than the previous iteration.

//AN_Xml: //AN_Xml:

In the case of harry.is, almost nothing changed since our previous variant. //AN_Xml:Visually complete was 200ms faster, but any first- metrics were untouched. //AN_Xml:It was seeing these results that actually spurred me to also test against CSS //AN_Xml:Wizardry. Because harry.is is such a small and simple page, there wasn’t much //AN_Xml:network contention for a print stylesheet to yield to—changing its priority //AN_Xml:didn’t really help it out much at all.

//AN_Xml: //AN_Xml:

In the case of CSS Wizardry, we see first paint 300ms slower, which is //AN_Xml:unexpected but unrelated (there is no render blocking CSS, so changing the //AN_Xml:priority of an asynchronous CSS file can have no bearing here—I’m going to chalk //AN_Xml:it up to an anomaly in testing). Happily, first contentful paint improved by //AN_Xml:200ms, first web font was 600ms faster, and visually complete was 700ms //AN_Xml:faster.

//AN_Xml: //AN_Xml:

preloading Google Fonts is a good idea.

//AN_Xml: //AN_Xml:

`preconnect`

//AN_Xml: //AN_Xml:

The last piece of the puzzle I wanted to solve the trip to yet-another origin. //AN_Xml:While we link out to fonts.googleapis.com for our CSS, the font files //AN_Xml:themselves are hosted on fonts.gstatic.com. On a high-latency connection, this //AN_Xml:spells bad news.

//AN_Xml: //AN_Xml:

Google Fonts are good to us—they preconnect the fonts.gstatic.com origin //AN_Xml:preemptively via an HTTP header attached to the fonts.googleapis.com response:

//AN_Xml: //AN_Xml:

While not all that effective in these demos, I wish more third-party //AN_Xml:providers would do things like this.

//AN_Xml: //AN_Xml: //AN_Xml:

However, the execution of this header is bound by the response’s TTFB, which on //AN_Xml:high-latency networks can be very, very high. The median TTFB (including request //AN_Xml:queueing, DNS, TCP, TLS, and server time) for the Google Fonts CSS file across //AN_Xml:all tests was 1406ms. Conversely, the median download time for the CSS file was //AN_Xml:just 9.5ms—it took 148× longer to get to the headers of the file than it did to //AN_Xml:download the file itself.

//AN_Xml: //AN_Xml:

Put another way: even though Google are preconnecting the fonts.gstatic.com //AN_Xml:origin for us, they’re only gaining about a 10ms head-start. Put another-other //AN_Xml:way, this file is latency-bound, not //AN_Xml:bandwidth-bound.

//AN_Xml: //AN_Xml:

If we implement a first-party preconnect, we should stand to make some pretty //AN_Xml:huge gains. Let’s see what happens.

//AN_Xml: //AN_Xml:

Snippet:

//AN_Xml: //AN_Xml:

<link rel="preconnect"
//AN_Xml:      href="https://fonts.gstatic.com"
//AN_Xml:      crossorigin />
//AN_Xml:
//AN_Xml:<link rel="preload"
//AN_Xml:      as="style"
//AN_Xml:      href="$CSS&display=swap" />
//AN_Xml:
//AN_Xml:<link rel="stylesheet"
//AN_Xml:      href="$CSS&display=swap"
//AN_Xml:      media="print" onload="this.media='all'" />

//AN_Xml: //AN_Xml:

We can visualise the benefits well in WebPageTest:

//AN_Xml: //AN_Xml:

See just how much we can bring connection overhead forward with //AN_Xml:preconnect.

//AN_Xml: //AN_Xml: //AN_Xml:

Results – harry.is:

	FP	FCP	FWF	VC	Lighthouse
	1.8	1.8	3.8	4.4	100
Change from Baseline	−1.6	−2.8	−1.1	−0.6	+2
Change from Previous	0	0	−0.7	−0.9	0

//AN_Xml: //AN_Xml:

Results – CSS Wizardry:

	FP	FCP	FWF	VC	Lighthouse
	1.9	1.9	3.5	3.6	99
Change from Baseline	−1.5	−2.4	−0.9	−0.8	+3
Change from Previous	−0.1	−0.1	−0.8	−0.7	+1

//AN_Xml: //AN_Xml:

Here we go! First (contentful) paint is realistically untouched. Any changes //AN_Xml:here are unrelated to our preconnect as the preconnect only impacts //AN_Xml:resources after the critical path. Our focus is on first web font and visually //AN_Xml:complete, both of which show tremendous improvement. 700–1,200ms improvement //AN_Xml:on first web font and 700–900ms improvement on visually complete against //AN_Xml:our previous variant, and 600–900ms and 600–800ms respective improvements //AN_Xml:against our baseline. Lighthouse scores are sitting pretty at 100 and 99.

//AN_Xml: //AN_Xml:

preconnecting fonts.gstatic.com is a good idea.

//AN_Xml: //AN_Xml:

Bonus: `font-display: optional;`

//AN_Xml: //AN_Xml:

Using asynchronous CSS and font-display leaves us susceptible to FOUT (or, //AN_Xml:hopefully, FOFT if we’ve designed our Fallbacks properly). To try and //AN_Xml:mitigate this, I decided to run a test using font-display: optional;.

//AN_Xml: //AN_Xml:

This variation tells the browser that web fonts are considered optional, and if //AN_Xml:we can’t get hold of the font files during our extremely small block //AN_Xml:period then we offer no swap period. The practical upshot of which is //AN_Xml:that in the event that the web fonts takes too long to load, that pageview won’t //AN_Xml:utilise it at all. This helps to prevent the FOUT which will in turn lead to //AN_Xml:a more stable experience for your user—they won’t see text restyle part-way //AN_Xml:through their pageview—and a better Cumulative Layout Shift score.

//AN_Xml: //AN_Xml:

However, this proved consistently troublesome when using asynchronous CSS. When //AN_Xml:the print stylesheet gets turned into an all stylesheet, the browser updates //AN_Xml:the CSSOM then applies it against the DOM. In this moment, the page is told it //AN_Xml:needs some web fonts, and the extremely small block period kicks in, //AN_Xml:showing a FOIT midway through the page load lifecycle. To make things worse, the //AN_Xml:browser will replace the FOIT with the same fallback it started with, so the //AN_Xml:user doesn’t even get the benefit of a new font. It basically looks like a bug.

//AN_Xml: //AN_Xml:

It’s much easier to visualise it than it is to explain, so here’s a screenshot //AN_Xml:of the filmstrip:

//AN_Xml: //AN_Xml:

Note the FOIT at 3.4–3.5s and 3.2s respectively.

//AN_Xml: //AN_Xml: //AN_Xml:

And a video showing the issue in DevTools:

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

//AN_Xml:Can’t see the //AN_Xml:video? Click here. //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml:

I would not recommend using font-disply: optional; alongside asynchronous //AN_Xml:CSS; I would recommend using asynchronous CSS. Ergo, I would not recommend //AN_Xml:font-display: optional;. It’s better overall to have non-blocking CSS with //AN_Xml:a FOUT than it is to have the needless FOIT.

//AN_Xml: //AN_Xml:

Comparisons and Visualisations

//AN_Xml: //AN_Xml:

In these slow-motion videos, you can see the differences quite clearly.

//AN_Xml: //AN_Xml:

harry.is

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

Can’t see //AN_Xml:the video? Click here.

//AN_Xml: //AN_Xml: //AN_Xml:

Async, preload, and preconnect all start rendering at 1.8s. //AN_Xml:
- This also represents their first contentful paints—useful information in the //AN_Xml:first render.
//AN_Xml:
Legacy and swap both start rendering at 3.4s. //AN_Xml:
- Though legacy is missing any text—FOIT.
//AN_Xml:
preconnect loads its web font at 3.8s. //AN_Xml:
- It’s deemed visually complete at 4.4s.
//AN_Xml:
Legacy makes its first contentful and first web font paint at 4.5s. //AN_Xml:
- They’re one and the same as everything is synchronous.
//AN_Xml:
Legacy’s visually complete is at 5s.
Async’s visually complete comes in at 5.1s.
swap is deemed complete at 5.2s.
preload is deemed visually complete at 5.3s.

//AN_Xml: //AN_Xml:

CSS Wizardry

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

//AN_Xml:Can’t //AN_Xml:see the video? Click here. //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml:

Async starts rendering at 1.7s.
preconnect starts rendering at 1.9s. //AN_Xml:
- Its first contentful paint is also 1.9s—useful information in the first //AN_Xml:render.
//AN_Xml:
preload starts rendering at 2s. //AN_Xml:
- Its first contentful paint is also at 2s.
//AN_Xml:
Async renders content at 2.2s.
Legacy starts rendering at 3.4s.
swap makes it first- and first contentful paint at 3.6s.
preconnect is deemed visually complete at 3.6s.
Legacy makes its first contentful paint at 4.3s.
preload is visually complete at 4.3s.
Legacy is considered visually complete at 4.4s.
swap completes at 4.6s.
Async comes in last at 5s.

//AN_Xml: //AN_Xml:

preconnect is fastest across all metrics

//AN_Xml: //AN_Xml:

Findings

//AN_Xml: //AN_Xml:

While self-hosting your web fonts is likely to be the overall best solution to //AN_Xml:performance and availability problems, we’re able to design some fairly //AN_Xml:resilient measures to help mitigate a lot of these issues when using Google //AN_Xml:Fonts.

//AN_Xml: //AN_Xml:

A combination of asynchronously loading CSS, asynchronously loading font files, //AN_Xml:opting into FOFT, fast-fetching asynchronous CSS files, and warming up external //AN_Xml:domains makes for an experience several seconds faster than the baseline.

//AN_Xml: //AN_Xml:

This is something that I strongly recommend adopting if you are a Google Fonts //AN_Xml:user.

//AN_Xml: //AN_Xml:

If Google Fonts isn’t your only render-blocking resource, and if you’re //AN_Xml:violating any of the other principles for fast //AN_Xml:CSS (e.g. if //AN_Xml:you’re @importing your Google Fonts CSS file), then your mileage will vary. //AN_Xml:These optimisations are most beneficial on project where Google Fonts is posing //AN_Xml:one of your biggest performance bottlenecks.

//AN_Xml: //AN_Xml:

Google Fonts Async Snippet

//AN_Xml: //AN_Xml:

There a lot of techniques combined here, but the resulting code is still slim //AN_Xml:and maintainable enough that it should’t pose a problem. The snippet doesn’t //AN_Xml:need breaking apart and can all be kept together in the <head> of your //AN_Xml:document.

//AN_Xml: //AN_Xml:

Here is the optimum snippet to use for fast Google Fonts:

//AN_Xml: //AN_Xml:

<!--
//AN_Xml:  - 1. Preemptively warm up the fonts’ origin.
//AN_Xml:  -
//AN_Xml:  - 2. Initiate a high-priority, asynchronous fetch for the CSS file. Works in
//AN_Xml:  -    most modern browsers.
//AN_Xml:  -
//AN_Xml:  - 3. Initiate a low-priority, asynchronous fetch that gets applied to the page
//AN_Xml:  -    only after it’s arrived. Works in all browsers with JavaScript enabled.
//AN_Xml:  -
//AN_Xml:  - 4. In the unlikely event that a visitor has intentionally disabled
//AN_Xml:  -    JavaScript, fall back to the original method. The good news is that,
//AN_Xml:  -    although this is a render-blocking request, it can still make use of the
//AN_Xml:  -    preconnect which makes it marginally faster than the default.
//AN_Xml:  -->
//AN_Xml:
//AN_Xml:<!-- [1] -->
//AN_Xml:<link rel="preconnect"
//AN_Xml:      href="https://fonts.gstatic.com"
//AN_Xml:      crossorigin />
//AN_Xml:
//AN_Xml:<!-- [2] -->
//AN_Xml:<link rel="preload"
//AN_Xml:      as="style"
//AN_Xml:      href="$CSS&display=swap" />
//AN_Xml:
//AN_Xml:<!-- [3] -->
//AN_Xml:<link rel="stylesheet"
//AN_Xml:      href="$CSS&display=swap"
//AN_Xml:      media="print" onload="this.media='all'" />
//AN_Xml:
//AN_Xml:<!-- [4] -->
//AN_Xml:<noscript>
//AN_Xml:  <link rel="stylesheet"
//AN_Xml:        href="$CSS&display=swap" />
//AN_Xml:</noscript>

//AN_Xml: //AN_Xml:

Real-World Effectiveness of Brotli

Wed, 22 Apr 2020 10:28:20 +0000

One of the more fundamental rules of building fast websites is to optimise your //AN_Xml:assets, and where text content such as HTML, CSS, and JS are concerned, we’re //AN_Xml:talking about compression.

//AN_Xml: //AN_Xml:

The de facto text-compression of the web is Gzip, with around 80% of compressed //AN_Xml:responses favouring that algorithm, and the remaining 20% use the much newer //AN_Xml:Brotli.

//AN_Xml: //AN_Xml:

Of course, this total of 100% only measures compressible responses that //AN_Xml:actually were compressed—there are still many millions of resources that could //AN_Xml:or should have been compressed but were not. For a more detailed breakdown of //AN_Xml:the numbers, see the //AN_Xml:Compression section of //AN_Xml:the Web Almanac.

//AN_Xml: //AN_Xml:

Gzip is tremendously effective. The entire works of Shakespeare weigh in at //AN_Xml:5.3MB in plain-text format; after Gzip (compression level 6), that number comes //AN_Xml:down to 1.9MB. That’s a 2.8× decrease in file-size with zero loss of data. Nice!

//AN_Xml: //AN_Xml:

Even better for us, Gzip favours repetition—the more repeated strings found in //AN_Xml:a text file, the more effective Gzip can be. This spells great news for the web, //AN_Xml:where HTML, CSS, and JS have a very consistent and repetitive syntax.

//AN_Xml: //AN_Xml:

But, while Gzip is highly effective, it’s old; it was released in 1992 (which //AN_Xml:certainly helps explain its ubiquity). 21 years later, in 2013, Google launched //AN_Xml:Brotli, a new algorithm that claims even greater improvement than Gzip! That //AN_Xml:same 5.2MB Shakespeare compilation comes down to 1.7MB when compressed with //AN_Xml:Brotli (compression level 6), giving a 3.1× decrease in file-size. Nicer!

//AN_Xml: //AN_Xml:

Using Paul Calvano’s Gzip and Brotli Compression Level //AN_Xml:Estimator!, you’re likely to //AN_Xml:find that certain files can earn staggering savings by using Brotli over Gzip. //AN_Xml:ReactDOM, for example, ends up 27% smaller when compressed with maximum-level //AN_Xml:Brotli compression (11) as opposed to with maximum-level Gzip (9).

//AN_Xml: //AN_Xml:

At all compression levels, Brotli always outperforms Gzip when //AN_Xml:compressing ReactDom. At Brotli’s maximum setting, it is 27% more effective than //AN_Xml:Gzip.

//AN_Xml: //AN_Xml: //AN_Xml:

And speaking purely anecdotally, moving a client of mine from Gzip to Brotli led //AN_Xml:to a median file-size saving of 31%.

//AN_Xml: //AN_Xml:

So, for the last several years, I, along with other performance engineers like //AN_Xml:me, have been recommending that our clients move over from Gzip and to Brotli //AN_Xml:instead.

//AN_Xml: //AN_Xml:

Browser Support: A brief interlude. While Gzip is so widely //AN_Xml:supported that Can I Use doesn’t even list tables for it (This HTTP header is //AN_Xml:supported in effectively all browsers (since IE6+, Firefox 2+, Chrome 1+ //AN_Xml:etc)), Brotli currently enjoys 93.17% worldwide //AN_Xml:support at the time of writing, which is //AN_Xml:huge! That said, if you’re a site of any reasonable size, serving uncompressed //AN_Xml:resources to over 6% of your customers might not sit too well with you. Well, //AN_Xml:you’re in luck. The way clients advertise their support for a particular //AN_Xml:algorithm works in a completely progressive manner, so users who can’t accept //AN_Xml:Brotli will simply fall back to Gzip. More on this later.

//AN_Xml: //AN_Xml:

For the most part, particularly if you’re using a CDN, enabling Brotli should //AN_Xml:just be the flick of a switch. It’s certainly that simple in Cloudflare, who //AN_Xml:I run CSS Wizardry through. However, a number of clients of mine in the past //AN_Xml:couple of years haven’t been quite so lucky. They were either running their own //AN_Xml:infrastructure and installing and deploying Brotli everywhere proved //AN_Xml:non-trivial, or they were using a CDN who didn’t have readily available support //AN_Xml:for the new algorithm.

//AN_Xml: //AN_Xml:

In instances where we were unable to enable Brotli, we were always left //AN_Xml:wondering What if… So, finally, I’ve decided to attempt to quantify the //AN_Xml:question: how important is it that we move over to Brotli?

//AN_Xml: //AN_Xml:

Smaller Doesn’t Necessarily Mean Faster

//AN_Xml: //AN_Xml:

Usually, sure! Making a file smaller will make it arrive sooner, generally //AN_Xml:speaking. But making a file, say, 20% smaller will not make it arrive 20% //AN_Xml:earlier. This is because file-size is only one aspect of web performance, and //AN_Xml:whatever the file-size is, the resource is still sat on top of a lot of other //AN_Xml:factors and constants—latency, packet loss, etc. Put another way, file-size //AN_Xml:savings help you to cram data into lower bandwidth, but if you’re latency-bound, //AN_Xml:the speed at which those admittedly fewer chunks of data arrive will not change.

//AN_Xml: //AN_Xml:

TCP, Packets, and Round Trips

//AN_Xml: //AN_Xml:

Taking a very reductive and simplistic view of how files are transmitted from //AN_Xml:server to client, we need to look at TCP. When we receive a file from a sever, //AN_Xml:we don’t get the whole file in one go. TCP, upon which HTTP sits, breaks the //AN_Xml:file up into segments, or packets. Those packets are sent, in batches, in //AN_Xml:order, to the client. They are each acknowledged before the next series of //AN_Xml:packets is transferred until the client has all of them, none are left on the //AN_Xml:server, and the client can reassemble them into what we might recognise as //AN_Xml:a file. Each batch of packets gets sent in a round trip.

//AN_Xml: //AN_Xml:

Each new TCP connection has no way of knowing what bandwidth it currently has //AN_Xml:available to it, nor how reliable the connection is (i.e. packet loss). If the //AN_Xml:server tried to send a megabyte’s worth of packets over a connection that only //AN_Xml:has capacity for one megabit, it’s going to flood that connection and cause //AN_Xml:congestion. Conversely, if it was to try and send one megabit of data over //AN_Xml:a connection that had one megabyte available to it, it’s not gaining full //AN_Xml:utilisation and lots of capacity is going to waste.

//AN_Xml: //AN_Xml:

To tackle this little conundrum, TCP utilises a mechanism known as slow start. //AN_Xml:Each new TCP connection limits itself to sending just 10 packets of data in its //AN_Xml:first round trip. Ten TCP segments equates to roughly 14KB of data. If those ten //AN_Xml:segments arrive successfully, the next round trip will carry 20 packets, then //AN_Xml:40, 80, 160, and so on. This exponential growth continues until one of two //AN_Xml:things happens:

//AN_Xml: //AN_Xml:

we suffer packet loss, at which point the server will halve whatever the last //AN_Xml:number of attempted packets were and retry, or;
we max out our bandwidth and can run at full capacity.

//AN_Xml: //AN_Xml:

This simple, elegant strategy manages to balance caution with optimism, and //AN_Xml:applies to every new TCP connection that your web application makes.

//AN_Xml: //AN_Xml:

Put simply: your initial bandwidth capacity on a new TCP connection is only //AN_Xml:about 14KB. Or roughly 11.8% of uncompressed ReactDom; 36.94% of Gzipped //AN_Xml:ReactDom; or 42.38% of Brotlied ReactDom (both set to maximum compression).

//AN_Xml: //AN_Xml:

Wait. The leap from 11.8% to 36.94% is pretty notable! But the change from //AN_Xml:36.94% to 42.38% is much less impressive. What’s going on?

Round Trips	TCP Capacity (KB)	Cumulative Transfer (KB)	ReactDom Transferred By…
1	14	14
2	28	42	Gzip (37.904KB), Brotli (33.036KB)
3	56	98
4	112	210	Uncompressed (118.656KB)
5	224	434

//AN_Xml: //AN_Xml:

Both the Gzipped and Brotlied versions of ReactDom fit into the same round-trip //AN_Xml:bucket: just two round trips to get the full file transferred. If all round trip //AN_Xml:times (RTT) are fairly uniform, this means there’s no difference in transfer //AN_Xml:time between Gzip and Brotli here.

//AN_Xml: //AN_Xml:

The uncompressed version, on the other hand, takes a full two round trips more //AN_Xml:to be fully transferred, which—particularly on a high latency connection—could //AN_Xml:be quite noticeable.

//AN_Xml: //AN_Xml:

The point I’m driving at here is that it’s not just about file-size, it’s about //AN_Xml:TCP, packets, and round trips. We don’t just want to make files smaller, we //AN_Xml:want to make them meaningfully smaller, nudging them into lower round trip //AN_Xml:buckets.

//AN_Xml: //AN_Xml:

This means that, in theory, for Brotli to be notably more effective than Gzip, //AN_Xml:it will need to be able to compress files quite a lot more aggressively so as to //AN_Xml:move it beneath round trip thresholds. I’m not sure how well it’s going to stack //AN_Xml:up…

//AN_Xml: //AN_Xml:

It’s worth noting that this model is quite aggressively simplified, and //AN_Xml:there are myriad more factors to take into account: is the TCP connection new or //AN_Xml:not, is it being used for anything else, is server-side prioritisation //AN_Xml:stop-starting transfer, do H/2 streams have exclusive access to bandwidth? This //AN_Xml:section is a more academic assessment and should be seen as a good jump-off //AN_Xml:point, but consider analysing the data properly in something like Wireshark, and //AN_Xml:also read Barry Pollard’s far more forensic //AN_Xml:analysis of the magic 14KB in his Critical Resources and the First 14 KB //AN_Xml:– A Review.

//AN_Xml: //AN_Xml:

This rule also only applies to brand new TCP connections, and any files fetched //AN_Xml:over primed TCP connections will not be subject to slow start. This brings forth //AN_Xml:two important points:

//AN_Xml: //AN_Xml:

Not that it should need repeating: you need to self-host your static //AN_Xml:assets. //AN_Xml:This is a great way to avoid a slow start penalty, as using your own //AN_Xml:already-warmed up origin means your packets have access to greater bandwidth, //AN_Xml:which brings me to point two;
With exponential growth, you can see just how quickly we reach relatively //AN_Xml:massive bandwidths. The more we use or reuse connections, the further we can //AN_Xml:increase capacity until we top out. Let’s look at a continuation of the above //AN_Xml:table…

//AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

Round Trips	TCP Capacity (KB)	Cumulative Transfer (KB)
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1,778
8	1,792	3,570
9	3,584	7,154
10	7,168	14,322
…	…	…
20	7,340,032	14,680,050

//AN_Xml: //AN_Xml:

By the end of 10 round trips, we have a TCP capacity of 7,168KB and have already //AN_Xml:transferred a cumulative 14,322KB. This is more than adequate for casual web //AN_Xml:browsing (i.e. not ~~torrenting~~ streaming Game of Thrones). In actual fact, //AN_Xml:what usually happens here is that we end up loading the entire web page and all //AN_Xml:of its subresources before we even reach the limit of our bandwidth. Put another //AN_Xml:way, your 1Gbps¹ fibre line won’t make your day-to-day browsing feel much //AN_Xml:faster because most of it isn’t even getting used.

//AN_Xml: //AN_Xml:

By 20 round trips, we’re theoretically hitting a capacity of 7.34GB.

//AN_Xml: //AN_Xml:

What About the Real World?

//AN_Xml: //AN_Xml:

Okay, yeah. That all got a little theoretical and academic. I started off this //AN_Xml:whole train of thought because I wanted to see, realistically, what impact //AN_Xml:Brotli might have for real websites.

//AN_Xml: //AN_Xml:

The numbers so far show that the difference between no compression and Gzip are //AN_Xml:vast, whereas the difference between Gzip and Brotli are far more modest. This //AN_Xml:suggests that while the nothing to Gzip gains will be noticeable, the upgrade //AN_Xml:from Gzip to Brotli might perhaps be less impressive.

//AN_Xml: //AN_Xml:

I took a handful of example sites in which I tried to cover sites that were //AN_Xml:a good cross section of:

//AN_Xml: //AN_Xml:

relatively well known (it’s better to use demos that people can //AN_Xml:contextualise), and/or;
relevant and suitable for the test (i.e. of a reasonable size (compression is //AN_Xml:more relevant) and not formed predominantly of non-compressible content //AN_Xml:(like, for example YouTube)), and/or;
not all multi-billion dollar corporations (let’s use some normal case studies, //AN_Xml:too).

//AN_Xml: //AN_Xml:

With those requirements in place, I grabbed a selection of //AN_Xml:origins and began //AN_Xml:testing:

//AN_Xml: //AN_Xml:

m.facebook.com
www.linkedin.com
www.insider.com
yandex.com
www.esedirect.co.uk
www.story.one
www.cdm-bedrijfskleding.nl
www.everlane.com

//AN_Xml: //AN_Xml:

I wanted to keep the test simple, so I grabbed only:

//AN_Xml: //AN_Xml:

data transferred, and;
First contentful paint (FCP) times;
without compression;
with Gzip, and;
with Brotli.

//AN_Xml: //AN_Xml:

FCP feels like a real-world and universal enough metric to apply to any site, //AN_Xml:because that’s what people are there for—content. Also because Paul //AN_Xml:Calvano said so, and he’s smart: Brotli //AN_Xml:tends to make FCP faster in my experience, especially when the critical CSS/JS //AN_Xml:is large.

//AN_Xml: //AN_Xml:

Running the Tests

//AN_Xml: //AN_Xml:

Here’s a bit of a dirty secret. A lot of web performance case studies—not all, //AN_Xml:but a lot—aren’t based on improvements, but are often extrapolated and inferred //AN_Xml:from the opposite: slowdowns. For example, it’s much simpler for the BBC to say //AN_Xml:that they lose an additional 10% of //AN_Xml:users for every //AN_Xml:additional second it takes for their site to load than it is to work out //AN_Xml:what happens for a 1s speed-up. It’s much easier to make a site slower, which is //AN_Xml:why so many people seem to be so good at it.

//AN_Xml: //AN_Xml:

With that in mind, I didn’t want to find Gzipped sites and then try and somehow //AN_Xml:Brotli them offline. Instead, I took Brotlied websites and turned off Brotli. //AN_Xml:I worked back from Brotli to Gzip, then Gzip to to nothing, and measured the //AN_Xml:impact that each option had.

//AN_Xml: //AN_Xml:

Although I can’t exactly hop onto LinkedIn’s servers and disable Brotli, I can //AN_Xml:instead choose to request the site from a browser that doesn’t support Brotli. //AN_Xml:And although I can’t exactly disable Brotli in Chrome, I can hide from the //AN_Xml:server the fact that Brotli is supported. The way a browser advertises its //AN_Xml:accepted compression algorithm(s) is via the content-encoding request header, //AN_Xml:and using WebPageTest, I can define my own. Easy!

//AN_Xml: //AN_Xml:

WebPageTest’s advanced feature allows us to set custom request //AN_Xml:headers.

//AN_Xml: //AN_Xml: //AN_Xml:

To disable compression entirely: accept-encoding: randomstring.
To disable Brotli but use Gzip instead: accept-encoding: gzip.
To use Brotli if it’s available (and the browser supports it): leave blank.

//AN_Xml: //AN_Xml:

I can then verify that things worked as planned by checking for the //AN_Xml:corresponding (or lack of) content-encoding header in the response.

//AN_Xml: //AN_Xml:

Findings

//AN_Xml: //AN_Xml:

As expected, going from nothing to Gzip has massive reward, but going from Gzip //AN_Xml:to Brotli was far less impressive. The raw data is available in this Google //AN_Xml:Sheet, //AN_Xml:but the things we mainly care about are:

//AN_Xml: //AN_Xml:

Gzip size reduction vs. nothing: 73% decrease
Gzip FCP improvement vs. nothing: 23.305% decrease
Brotli size reduction vs. Gzip: 5.767% decrease
Brotli FCP improvement vs. Gzip: 3.462% decrease

//AN_Xml: //AN_Xml:

All values are median; ‘Size’ refers to HTML, CSS, and JS only.

//AN_Xml: //AN_Xml:

Gzip made files 72% smaller than not compressing them at all, but Brotli only //AN_Xml:saved us an additional 5.7% over that. In terms of FCP, Gzip gave us a 23% //AN_Xml:improvement when compared to using nothing at all, but Brotli only gained us an //AN_Xml:extra 3.5% on top of that.

//AN_Xml: //AN_Xml:

While the results to seem to back up the theory, there are a few ways in which //AN_Xml:I could have improved the tests. The first would be to use a much larger sample //AN_Xml:size, and the other two I shall outline more fully below.

//AN_Xml: //AN_Xml:

First-Party vs. Third-Party

//AN_Xml: //AN_Xml:

In my tests, I disabled Brotli across the board and not just for the first party //AN_Xml:origin. This means that I wasn’t measuring solely the target’s benefits of using //AN_Xml:Brotli, but potentially all of their third parties as well. This only really //AN_Xml:becomes of interest to us if a target site has a third party on their critical //AN_Xml:path, but it is worth bearing in mind.

//AN_Xml: //AN_Xml:

Compression Levels

//AN_Xml: //AN_Xml:

When we talk about compression, we often discuss it in terms of best-case //AN_Xml:scenarios: level-9 Gzip and level-11 Brotli. However, it’s unlikely that your //AN_Xml:web server is configured in the most optimal way. Apache’s default Gzip //AN_Xml:compression level is 6, but Nginx is set to just 1.

//AN_Xml: //AN_Xml:

Disabling Brotli means we fall back to Gzip, and given how I am testing the //AN_Xml:sites, I can’t alter or influence any configurations or fallbacks’ //AN_Xml:configurations. I mention this because two sites in the test actually got larger //AN_Xml:when we enabled Brotli. To me this suggests that their Gzip compression level //AN_Xml:was set to a higher value than their Brotli level, making Gzip more effective.

//AN_Xml: //AN_Xml:

Compression levels are a trade-off. Ideally you’d like to set everything to the //AN_Xml:highest setting and be done, but that’s not really practical—the time taken on //AN_Xml:the server to do that dynamically would likely nullify the benefits of //AN_Xml:compression in the first place. To combat this, we have two options:

//AN_Xml: //AN_Xml:

use a pragmatic compression level that balances speed and effectiveness //AN_Xml:when dynamically compressing assets, or;
upload precompressed static assets with a much higher compression level, //AN_Xml:and use the first option for dynamic responses.

//AN_Xml: //AN_Xml:

So What?

//AN_Xml: //AN_Xml:

It would seem that, realistically, the benefits of Brotli over Gzip are slight.

//AN_Xml: //AN_Xml:

If enabling Brotli is as simple as flicking a checkbox in the admin panel of //AN_Xml:your CDN, please go ahead and do it right now: support is wide enough, fallbacks //AN_Xml:are simple, and even minimal improvements are better than none at all.

//AN_Xml: //AN_Xml:

Where possible, upload precompressed static assets to your web server with the //AN_Xml:highest possible compression setting, and use something more middle-ground for //AN_Xml:anything dynamic. If you’re running on Nginx, please ensure you aren’t still on //AN_Xml:their pitiful default compression level of 1.

//AN_Xml: //AN_Xml:

However, if you’re faced with the prospect of weeks of engineering, test, and //AN_Xml:deployment efforts to get Brotli live, don’t panic too much—just make sure you //AN_Xml:have Gzip on everything that you can compress (that includes your .ico and //AN_Xml:.ttf files, if you have any).

//AN_Xml: //AN_Xml:

I guess the short version of the story is that if you haven’t or can’t enable //AN_Xml:Brotli, you’re not missing out on much.

//AN_Xml: //AN_Xml:

//AN_Xml:

//AN_Xml:
That 1Gbps you’re getting sold actually equates to 0.125GBps. ISPs hide their false advertising in plain sight. ↩
//AN_Xml:

//AN_Xml:

Performance Budgets, Pragmatically

Wed, 08 Jan 2020 18:19:10 +0000

One of the key tools that performance engineers have at their disposal is the //AN_Xml:Performance Budget: it helps us—or, more importantly, our clients—ensure that //AN_Xml:any performance-focused work is monitored and maintained after we’ve gone.

//AN_Xml: //AN_Xml:

By establishing an acceptable threshold, be that based on RUM data, bundle //AN_Xml:analysis, image weight, milestone timings, or any other suitable metric, we can //AN_Xml:be sure that new or unrelated bodies of work do not have a detrimental impact on //AN_Xml:the performance of our site.

//AN_Xml: //AN_Xml:

The difficulty, however, lies in actually defining those thresholds. This post //AN_Xml:is for anyone who has struggled with the question, But what should our //AN_Xml:budgets actually be?!

//AN_Xml: //AN_Xml:

Targets vs. Safeguards

//AN_Xml: //AN_Xml:

When faced with the task of setting a brand new budget, it can feel //AN_Xml:daunting—almost paralysing—trying to find a value that is both attainable but //AN_Xml:effective. Is it too ambitious? Is it not ambitious enough? Is it going to be //AN_Xml:really difficult to hit? Or do we risk making it so easy to achieve that it’s //AN_Xml:almost pointless? How do we know? How long will it take to find out?

//AN_Xml: //AN_Xml:

Here’s the thing: most organisations aren’t ready for challenges, they’re in //AN_Xml:need of safety nets. Performance budgets should not be things to work toward, //AN_Xml:they should be things that stop us slipping past a certain point. They shouldn’t //AN_Xml:be aspirational, they should be preventative.

//AN_Xml: //AN_Xml:

Time and again I hear clients discussing their performance budgets in terms of //AN_Xml:goals: We’re aiming toward a budget of 250KB uncompressed JavaScript; //AN_Xml:we hope to be interactive in 2.75s. While it’s absolutely vital that //AN_Xml:these goals exist and are actively worked toward, this is not part of your //AN_Xml:budgeting. Your budgeting is actually far, far simpler:

//AN_Xml: //AN_Xml:

Our budget for [metric] is never-worse-than-it-is-right-now.

//AN_Xml: //AN_Xml:

The Last Two Weeks

//AN_Xml: //AN_Xml:

Whatever monitoring you use (I adore SpeedCurve and //AN_Xml:Treo), my suggestion for setting a budget for any trackable //AN_Xml:metric is to take the worst data point in the past two weeks and use that as //AN_Xml:your limit. Load times were 7.2s? You’re not allowed to get any slower than //AN_Xml:that. JS size was 478KB? You can’t introduce any more without refactoring what’s //AN_Xml:already there. 68 third party requests? You can’t add any more.

//AN_Xml: //AN_Xml:

Then, every two weeks, you revisit your monitoring and one of three things can //AN_Xml:happen:

//AN_Xml: //AN_Xml:

Your new worst-point is better than the last one: This is the best //AN_Xml:outcome! Let’s say you went from a 7.2s load time and now your worst value is //AN_Xml:6.8s—well done! Now your budget gets updated to 6.8s and your job is to not //AN_Xml:regress beyond that.
Your new worst-point is the same as the last one: This is still good //AN_Xml:news—we haven’t regressed! But we haven’t improved, either. In this scenario, //AN_Xml:we don’t need to do anything. Instead, we just leave the budget as it was and //AN_Xml:hope we can continue on the same path.
Your new worst-point is worse than the last one: Uh oh. This is bad news. //AN_Xml:Things have slipped. In this scenario, we do not alter the budget. We can’t //AN_Xml:increase budgets unless there is a very valid and agreed reason to do so. //AN_Xml:Instead, we double down on solving the problem and getting back on track.

//AN_Xml: //AN_Xml:

By constantly revisiting and redefining budgets in two-weekly snapshots, we’re //AN_Xml:able to make slow, steady, and incremental improvements. But the key thing to //AN_Xml:remember is that we can’t ever increase a performance budget; we can’t change //AN_Xml:the test just to make it passable. We can maintain or decrease one, but we can’t //AN_Xml:increase it, because that would completely undermine them.

//AN_Xml: //AN_Xml:

Example Performance Budgets

//AN_Xml: //AN_Xml:

The following SpeedCurve charts respectively show the Visually Complete, Start //AN_Xml:Render, and Fully Loaded budgets for CSS Wizardry over a 3G Galaxy S4 from the //AN_Xml:UK.

//AN_Xml: //AN_Xml:

Under Budget

//AN_Xml: //AN_Xml:

Well under budget for Visually Complete every single day. (View full size.)

//AN_Xml: //AN_Xml: //AN_Xml:

I’ve set a Visually Complete budget of 3s, but I’m doing far better than that //AN_Xml:every single day across the last fortnight. The slowest Start Render in that //AN_Xml:period was 2.4s, so I need to update my budget accordingly and maintain the new //AN_Xml:maximum for the next two weeks before revisiting once more.

//AN_Xml: //AN_Xml:

On Budget

//AN_Xml: //AN_Xml:

Hitting the Start Render threshold four days out of 14. (View full size.)

//AN_Xml: //AN_Xml: //AN_Xml:

With an allotted budget of 2s for Start Render, I find that on most days I am //AN_Xml:actually quite nicely under budget, which is great news. That said, on four //AN_Xml:occasions I am just nudging the line. This means that I need to be mindful over //AN_Xml:the next two weeks, but do not need to update anything. This budget is probably //AN_Xml:quite sensibly set as it’s clearly attainable, but is on the verge of needing //AN_Xml:some proactive input to keep within the bounds.

//AN_Xml: //AN_Xml:

Over Budget

//AN_Xml: //AN_Xml:

Completely overshooting the Fully Loaded budget every day. (View full size.)

//AN_Xml: //AN_Xml: //AN_Xml:

Uh oh. I’m completely overshooting my Fully Loaded time every single day, and //AN_Xml:sometimes by up to four seconds. I can’t reset the budget (unless it’s decided //AN_Xml:that for some reason 6s was completely incorrect in the first place) but I do //AN_Xml:have some work to do. Clearly I have decided that load times are important //AN_Xml:enough to be monitored, so I need to roll up my sleeves and get to work fixing //AN_Xml:things.

//AN_Xml: //AN_Xml:

Your Turn

//AN_Xml: //AN_Xml:

Setting performance budgets doesn’t need to be complex or confusing, you simply //AN_Xml:need some existing data, some monitoring, and to remember that budgets and //AN_Xml:targets are two different things. Don’t make life difficult by treating //AN_Xml:performance budgets as aspirations.

//AN_Xml:

Lazy Pre-Browsing with Prefetch

Thu, 15 Aug 2019 14:47:28 +0000

I’m working with a client at the moment who, unfortunately, has a blocking third //AN_Xml:party stylesheet that’s needed to successfully render one of their site’s key //AN_Xml:pages. Until we can design a more long-term solution (and that’s assuming we can //AN_Xml:at all) that can asynchronously load the file, I wanted to work out a way to //AN_Xml:minimise its impact.

//AN_Xml: //AN_Xml:

This is a regular <link rel="stylesheet"> that is, necessarily, defined in the //AN_Xml:<head>. This means that from a cold-cache, if a user were to land on this page //AN_Xml:for the first time, they’re absolutely going to take a performance hit—there’s //AN_Xml:just no way around it. The file needs to make it across the network successfully //AN_Xml:before the page can even begin to render.

//AN_Xml: //AN_Xml:

The thing is, although this is a key page, it’s not necessarily the first or //AN_Xml:only page that a user will visit in a session. In fact, it’s highly likely that //AN_Xml:they’ll visit a few other types of page before they encounter this one. This //AN_Xml:means that we can take advantage of the fact that users will most likely visit //AN_Xml:a different page before this one, and pay the network overhead up-front using //AN_Xml:prefetch. We might not be able to load the file asynchronously, but until //AN_Xml:then, let’s at least attempt to load it from HTTP cache rather than from the //AN_Xml:network.

//AN_Xml: //AN_Xml:

Defined as:

//AN_Xml: //AN_Xml:

//AN_Xml:
The prefetch link relation type is used to identify a resource that might be //AN_Xml:required by the next navigation, and that the user agent SHOULD fetch, such //AN_Xml:that the user agent can deliver a faster response once the resource is //AN_Xml:requested in the future.
//AN_Xml:

//AN_Xml: //AN_Xml:

…this is exactly what prefetch is designed for. So nothing groundbreaking //AN_Xml:here. But what I wanted to do is very tersely ensure that on pages that do //AN_Xml:require the file, we get a Highest priority CSS request, and on pages that do //AN_Xml:not need it, we get a Lowest priority request completely off of the Critical //AN_Xml:Path. This means we never get slower than the baseline, but hopefully will stand //AN_Xml:to get much faster simply by paying off our network overhead early:

//AN_Xml: //AN_Xml:

<link rel="<?php echo $page == 'home' ? 'stylesheet' : 'prefetch'; ?>"
//AN_Xml:      href="https://third-party.com/file.css" />
//AN_Xml:

//AN_Xml: //AN_Xml:

Now, the same line of HTML can cover both scenarios without the need for more //AN_Xml:intricate workflows. This snippet can remain unchanged in the <head> of every //AN_Xml:template.

//AN_Xml: //AN_Xml:

With this simple addition, I can either take the hit of a fully-blocking, //AN_Xml:cross-origin resource when I really need to, or I can lazily load the file and //AN_Xml:have it sat waiting in HTTP cache for use when it ultimately gets called up.

//AN_Xml:

Making Cloud.typography Fast(er)

Tue, 13 Aug 2019 09:51:11 +0000

Disclaimers:

//AN_Xml: //AN_Xml:

I was not approached or hired by //AN_Xml:Hoefler&Co or //AN_Xml:Cloud.typography to look into any of //AN_Xml:the following issues.
I disclosed all of the below to Cloud.typography and gave them ample //AN_Xml:opportunity to work together to solve the issues at the root of the problem. //AN_Xml:There was no appetite from them to do so, so I decided to make it all available //AN_Xml:for free anyway—a faster web benefits everyone.
All of the people I have dealt with seem like really, really nice folk. //AN_Xml:Nothing that follows is a reflection on any individuals. Please bear that in //AN_Xml:mind as you read.

//AN_Xml: //AN_Xml:

It all started, as these things often do, with a waterfall:

//AN_Xml: //AN_Xml:

So much to unpack in only a handful of entries! Can you see //AN_Xml:it? View //AN_Xml:full size (31KB)

//AN_Xml: //AN_Xml: //AN_Xml:

I was doing some cursory research and running a few tests against a potential //AN_Xml:client’s site so as to get a good understanding of the shape of things before we //AN_Xml:were to work together. Even in just the first 10 entries in the waterfall chart //AN_Xml:above, there were so many fascinating clues and tells that were made immediately //AN_Xml:apparent. I was struck by some interesting behaviour happening in the very early //AN_Xml:stages of the page-load lifecycle. Let’s pick it apart…

//AN_Xml: //AN_Xml:

Entry (9), for cloud.typography.com, has very high connection overhead //AN_Xml:(405ms in total), surprisingly large //AN_Xml:TTFB //AN_Xml:(210ms), and returns a 302 //AN_Xml:anyway. What’s going on here? Where are we getting redirected to? //AN_Xml:
- It turns out that Cloud.typography is redirecting the request to //AN_Xml:a client-owned CSS file hosted on fonts.[client].com: Note a Location: //AN_Xml:https://fonts.[client].com/[number]/[hash].css header.
//AN_Xml:
Entry (10) lives on a different origin again, so we have more connection //AN_Xml:overhead to contend with, and the file seems to take an incredibly long time //AN_Xml:to download (as evidenced by the sheer amount of dark green—sending data). //AN_Xml:Why does Cloud.typography redirect us to a file we own ourselves? Is there //AN_Xml:some kind of ‘release mechanism’ used to authenticate [client].com to use //AN_Xml:the font service? And why is the file so huge?! //AN_Xml:
- It turns out that Cloud.typography is a hybrid solution, somewhere between //AN_Xml:cloud- and self-hosted. An outgoing request from a whitelisted domain //AN_Xml:returns a 302, forwarding the request to a self-hosted CSS file that is //AN_Xml:optimised specifcally for your browser, OS, and UA (Google Fonts do //AN_Xml:something similar). The CSS file(s) that we host is provided by //AN_Xml:Cloud.typography. //AN_Xml:
  - In case you’re wondering, a non-whitelisted domain returns a 403 //AN_Xml:response.
  //AN_Xml:
- The file is so big because it actually contains all of our fonts as Base64 //AN_Xml:encoded data URIs.
//AN_Xml:
Finally, entry (3), a large JS file, doesn’t execute until the moment the CSS //AN_Xml:(entry (10)) has completed. From this, I can gather that entry (3) is //AN_Xml:a synchronous JS file that was defined in the HTML sometime after the CSS. //AN_Xml:
- How did I know this? Because synchronous JS defined anywhere after //AN_Xml:synchronous CSS will not execute while the CSS in question is in flight. JS //AN_Xml:can be blocked on CSSOM construction. The knock-on effects of this long CSS //AN_Xml:request chain are huge.
//AN_Xml:

//AN_Xml: //AN_Xml:

So, what are the performance implications of all of this?

//AN_Xml: //AN_Xml:

First up, even though the request to cloud.typography.com returns a 302 //AN_Xml:response with a text/html MIME type, its outgoing request is for CSS. This //AN_Xml:makes complete sense as the request is invoked by a <link rel="stylesheet" />. //AN_Xml:We can further verify this by noting the presence of an Accept: //AN_Xml:text/css,*/*;q=0.1 request header. Put simply, despite not ‘being’ CSS, this //AN_Xml:request sits on our Critical Path and therefore blocks rendering.

//AN_Xml: //AN_Xml:

To further exacerbate the problem, the 302 response has a Cache-Control: //AN_Xml:must-revalidate, private //AN_Xml:header, //AN_Xml:meaning that we will always make an outgoing request for this resource //AN_Xml:regardless of whether or not we’re hitting the site from a cold or a warm cache. //AN_Xml:Although this response has a 0B filesize, we will always take the latency hit on //AN_Xml:every single page view (and this response is basically 100% latency). On mobile //AN_Xml:connections, this can amount to whole seconds of delays, all sat on the Critical //AN_Xml:Path.

//AN_Xml: //AN_Xml:

Next up, we get sent to fonts.[client].com, which introduces yet more latency //AN_Xml:for the connection setup. (Please note that this phenomenon is specific to the //AN_Xml:way this company has implemented their own assets and has nothing at all to do //AN_Xml:with Cloud.typography.) Because this response is CSS, our critical request chain //AN_Xml:remains unbroken—this is all work taking place on the Critical Path.

//AN_Xml: //AN_Xml:

Once we’ve dealt with the connection overhead, we begin downloading a behemoth //AN_Xml:CSS file (271.3KB) that is packed with all of the fonts for the project encoded //AN_Xml:in Base64 data URIs. Base64 is absolutely terrible for //AN_Xml:performance, //AN_Xml:and, particularly where fonts are concerned, has the following issues:

//AN_Xml: //AN_Xml:

Base64 encoding assets into CSS moves more weight (therefore delays) onto the //AN_Xml:Critical Path, holding back our Start Render.
Base64 compresses terribly, meaning we can’t claw back much of the excessive, //AN_Xml:increased filesize.
Fonts are not usually downloaded until the Render Tree has been constructed //AN_Xml:and the browser knows that the current page actually needs them. This //AN_Xml:defensive measure by the browser ensures that only the fonts that are actually //AN_Xml:needed will ever be downloaded. By encoding the fonts into the CSS, all of the //AN_Xml:font data is downloaded regardless of whether the current page needs it or //AN_Xml:not: it’s incredibly wasteful.
By Base64 encoding our fonts, we end up in a situation where, technically, we //AN_Xml:don’t have any fonts at all: we just have CSS. The implication here is that //AN_Xml:we’ve now rendered any font-loading strategies completely ineffective: //AN_Xml:font-display can’t work if there are no fonts; the Font Loading API is //AN_Xml:useless if there are no fonts. Technically, what we have here is a CSS //AN_Xml:problem, not a font problem.

//AN_Xml: //AN_Xml:

The practical upshot of the above is that we have 1,363ms of render blocking CSS //AN_Xml:on our Critical Path for a first-time visit on a cable connection. A repeat view //AN_Xml:still cost us 280ms:

//AN_Xml: //AN_Xml:

Because the Cloud.typography ‘CSS file’ has //AN_Xml:a must-revalidate header, //AN_Xml:we still take the latency hit on repeat views. View //AN_Xml:full size (17KB)

//AN_Xml: //AN_Xml: //AN_Xml:

The final nail in the coffin is the fact that, because there are no font files, //AN_Xml:the browser is unable to employ any kind of decision about how to handle missing //AN_Xml:typefaces. Most browsers will display invisible text for three seconds and, if //AN_Xml:the webfont doesn’t make it onto the device in that time, will instead display //AN_Xml:fallback text. Once the webfont does arrive, we then swap to displaying that. //AN_Xml:This means that, once the page has started rendering, the user will go for, at //AN_Xml:most, three seconds unable to read any content.

//AN_Xml: //AN_Xml:

This all only works if there are actual font files to be negotiated. Because //AN_Xml:Cloud.typography’s fonts are actually just more CSS, the browser is unable to //AN_Xml:discern the two, and thus cannot offer a three-second grace period. This means //AN_Xml:that there’s a theoretically infinite period where we don’t just block the //AN_Xml:rendering of text, but we block the rendering of the whole page.

//AN_Xml: //AN_Xml:

If you’re interested in seeing a real-world example of this, consider the //AN_Xml:following filmstrip comparison.

//AN_Xml: //AN_Xml:

Post-It is a Cloud.typography customer, and the entire page stays blank until //AN_Xml:the Cloud.typography CSS file makes it onto the device. Grid By Example, on the //AN_Xml:other hand, uses Google Fonts (without any font-display configuration), which //AN_Xml:allows the browser to begin rendering the page in the absence of the webfonts.

//AN_Xml: //AN_Xml:

N.B. The two test cases are very, very different sites, so I’m not //AN_Xml:looking to directly compare any timings—that would be unfair—I merely want to //AN_Xml:highlight the phenomenon.

//AN_Xml: //AN_Xml:

On a 3G connection, Post-It’s Start Render is 16.8s. Removing Cloud.typography //AN_Xml:entirely improves that time by over //AN_Xml:48%, //AN_Xml:bringing it down to 8.7s.

//AN_Xml: //AN_Xml:

All the above issues combined mean that, unfortunately, Cloud.typography is slow //AN_Xml:by default. While I am a huge fan of the //AN_Xml:foundry, and some of //AN_Xml:the stunning typefaces they have produced, I cannot in good conscience recommend //AN_Xml:Cloud.typography as a credible font provider while this is their implementation. //AN_Xml:It is actively harmful for performance.

//AN_Xml: //AN_Xml:

Solving the Problem for the Client

//AN_Xml: //AN_Xml:

The solutions I implemented for my client were mitigations at best—the problems //AN_Xml:still exist in Cloud.typography, but I was able to do a handful of things to //AN_Xml:take the edge off of how the problems were manifesting themselves.

//AN_Xml: //AN_Xml:

First up, I wanted to unblock the JS execution: there was no need to hold back //AN_Xml:the main app.js bundles for the sake of the fonts. The fix? Simple: swap their //AN_Xml:<link rel="stylesheet" /> and <script> lines around in their HTML:

//AN_Xml: //AN_Xml:

Before:

//AN_Xml: //AN_Xml:

<link rel="stylesheet" href="https://cloud.typography.com/[number]/[number]/css/fonts.css" />
//AN_Xml:<script src="https://www.[client].com/packs/application-[hash].js"><AN_Scri>

//AN_Xml: //AN_Xml:

After:

//AN_Xml: //AN_Xml:

<script src="https://www.[client].com/packs/application-[hash].js"><AN_Scri>
//AN_Xml:<link rel="stylesheet" href="https://cloud.typography.com/[number]/[number]/css/fonts.css" />

//AN_Xml: //AN_Xml:

Yes. As simple as that. Note now that entry (3) executes before the //AN_Xml:fonts.[client].com file has even begun downloading.

//AN_Xml: //AN_Xml:

By loading the CSS after our JS, the JS can run much sooner. View full size (29KB)

//AN_Xml: //AN_Xml: //AN_Xml:

My second tactic was to pay the connection cost for fonts.[client].com //AN_Xml:up-front by simply preconnecting to that origin. Early in the <head>:

//AN_Xml: //AN_Xml:

<link rel="preconnect" href="https://fonts.[client].com" />

//AN_Xml: //AN_Xml:

Note entry (11) in which we’re dealing with a whopping 397ms of connection //AN_Xml:overhead off of the Critical Path.

//AN_Xml: //AN_Xml:

These two small changes led to a 300ms improvement in Start Render and //AN_Xml:a staggering 1,504ms improvement in TTI at the 50th percentile.

//AN_Xml: //AN_Xml:

N.B. Remember, neither of these changes are solving any of the issues //AN_Xml:inherently present in Cloud.typography. All I’m doing here is mitigating the //AN_Xml:issues as best I can on the client’s end.

//AN_Xml: //AN_Xml:

//AN_Xml:

Let’s Talk

//AN_Xml:

Need some of the same?

//AN_Xml:

I’m available for hire to help you out with workshops, consultancy, advice, and development.

//AN_Xml:

//AN_Xml: //AN_Xml:

Solving the Problem for Everyone

//AN_Xml: //AN_Xml:

We’re over 1,300 words in and I haven’t even explicitly addressed the crux of //AN_Xml:the issue: Cloud.typography doesn’t give us font performance issues, it gives //AN_Xml:us CSS performance issues. Because the fonts are Base64 encoded, there are //AN_Xml:no fonts. This means that no amount of font-display, Font Loading API, Font //AN_Xml:Face Observer, etc. are going to help us. How do we solve this problem at the //AN_Xml:source? I got in touch with Cloud.typography.

//AN_Xml: //AN_Xml:

Reaching Out

//AN_Xml: //AN_Xml:

Honestly, I started off somewhat confused. With uncacheable, cross-origin //AN_Xml:redirects on the Critical Path and Base64 encoded fonts, this seems like a very //AN_Xml:slow way of delivering assets. So, naturally, I wanted to check that we weren’t //AN_Xml:doing anything wrong. I also wanted to understand the end to end workings of the //AN_Xml:solution more thoroughly so I’d be better poised to make recommendations.

//AN_Xml: //AN_Xml:

I got the details of a member of the team at Hoefler&Co and asked if I could //AN_Xml:send them some questions pertaining to their cloud service. If you’re //AN_Xml:interested, you can read the unedited email in full.

//AN_Xml: //AN_Xml:

The response I got shed some light on a few things. To summarise:

//AN_Xml: //AN_Xml:

the client was implementing everything correctly;
the redirect doesn’t ‘release’ the fonts for usage, but actually gathers some //AN_Xml:information about your browser and OS and forwards the request to the correct //AN_Xml:one of many CSS files that Cloud.typography provide you to self host; //AN_Xml:
- The Location of the redirect depends heavily on the User Agent making the //AN_Xml:request, so you can’t circumvent the trip to Cloud.typography.
- (Author’s note: But make no mistake, the redirect exists primarily for //AN_Xml:usage tracking, otherwise they’d cache it.)
//AN_Xml:
the cloud service is aimed at developers and agencies who might need access to //AN_Xml:a larger library to fulfil many different projects;
the self-hosted option is aimed at companies who have a limited and //AN_Xml:rigidly-defined font palette (think more enterprisey customers);
anyone concerned about performance is encouraged to upgrade to the self-hosted //AN_Xml:plan.

//AN_Xml: //AN_Xml:

I’m incredibly grateful for the person’s time and patience—I just popped on //AN_Xml:their radar out of nowhere and had quite a barrage of questions and, I’ll admit, //AN_Xml:critique for them. Their replies were insightful and timely.

//AN_Xml: //AN_Xml:

However, here’s where I end up a little disheartened: despite clearly outlining //AN_Xml:the tangible impact that Cloud.typography has on performance, there was no //AN_Xml:interest in looking at ways to remedy the problems. There was no appetite for //AN_Xml:providing or even documenting the alternative (i.e. not replacement—the //AN_Xml:current method would remain fully functional and valid) non-blocking loading //AN_Xml:strategy.

//AN_Xml: //AN_Xml:

I came up with a proof-of-concept alternative loading strategy that didn’t block //AN_Xml:rendering, instead opting to load the assets asynchronously in exchange for //AN_Xml:a flash of fallback text (FOFT), akin to implementing font-display: swap;, //AN_Xml:I was told Customers overwhelmingly prefer to not have their pages load //AN_Xml:sans-fonts and then “pop” into place with the correct fonts… which, of //AN_Xml:course, I, every async font loading strategy, and the entire font-display/Font //AN_Xml:Loading spec disagree with.

//AN_Xml: //AN_Xml:

I ascertained that approximately 13,100 sites in the HTTP Archive currently use //AN_Xml:Hoefler&Co’s Cloud.typography service. That’s approximately $15.5m //AN_Xml:a year worth of //AN_Xml:customers currently bound to a slow-by-design, slow-by-default webfont solution //AN_Xml:that we could have helped out!

//AN_Xml: //AN_Xml:

It’s a real shame, as the solution was trivial and I’d done all the legwork, but //AN_Xml:that’s life.

//AN_Xml: //AN_Xml:

The Solution

//AN_Xml: //AN_Xml:

To reiterate: we don’t have a webfont problem, we have a CSS problem. With //AN_Xml:this in mind, the solution to the problem becomes devilishly simple: we just //AN_Xml:need to lazy-load our CSS. By lazy-loading our font stylesheet, we move it off //AN_Xml:of the Critical Path and unblock rendering.

//AN_Xml: //AN_Xml:

Since the advent of Critical CSS, lazy-loading stylesheets has become more and //AN_Xml:more commonplace, with Filament Group’s latest //AN_Xml:method being by far the //AN_Xml:simplest and the most widely supported:

//AN_Xml: //AN_Xml:

<link rel="stylesheet" href="https://cloud.typography.com/[number]/[number]/css/fonts.css"
//AN_Xml:      media="print" onload="this.media='all'" />

//AN_Xml: //AN_Xml:

The magic lies in the second line. By setting a non-matching media type, the //AN_Xml:browser naturally loads the stylesheet with a low priority off of the Critical //AN_Xml:Path. Once the file has loaded, the inline onload event handler swaps to //AN_Xml:a matching media type, and this change then applies the stylesheet to the //AN_Xml:document, swapping the fonts in.

//AN_Xml: //AN_Xml:

The one caveat to this method is that we do now have a flash of fallback text //AN_Xml:(FOFT). This method of loading the stylesheet effectively synthesises //AN_Xml:font-display: swap;, immediately displaying a fallback typeface and replacing //AN_Xml:it with our chosen webfonts as soon as they become available. This means it’s //AN_Xml:going to be vital that you design a very robust, accurate fallback style for //AN_Xml:users to experience while we’re waiting for the proper fonts to arrive. //AN_Xml:Thankfully, Monica has made that a lot simpler //AN_Xml:by giving us Font Style Matcher.

//AN_Xml: //AN_Xml:

What makes me particularly fond of this method is that we’ve gone from arguably //AN_Xml:the slowest possible method of loading our assets to what might be the least //AN_Xml:intrusive. A complete inversion of the paradigm.

//AN_Xml: //AN_Xml:

Here’s a before and after over a 3G connection. The original implementation is //AN_Xml:on the left; my fixed version is on the right:

//AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml: //AN_Xml: Not //AN_Xml:seeing anything? Click right here! //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml:

Yes, we do have a FOFT, but we are getting text in front of the reader much, //AN_Xml:much sooner—this is an enormous improvement.

//AN_Xml: //AN_Xml:

Closing Thoughts

//AN_Xml: //AN_Xml:

I was genuinely disheartened by Cloud.typography’s indifference to the problems, //AN_Xml:especially considering the ‘fix’ would only require an update to the //AN_Xml:documentation. They wouldn’t have had to make any platform or infrastructure //AN_Xml:changes on their side. Further, they would still have been able to retain the //AN_Xml:same levels of control and fully track font usage, but completely //AN_Xml:asynchronously. It would have also been a great press-piece for them, announcing //AN_Xml:the release of a much faster method of including the same beautiful typefaces.

//AN_Xml: //AN_Xml:

That said, if you are a Cloud.typography customer, don’t panic. I would //AN_Xml:recommend exploring the asynchronous method I’ve outlined above. Implementation //AN_Xml:itself should be trivial, but you will need to invest some time in designing //AN_Xml:a suitable fallback style while your CSS is loading.

//AN_Xml: //AN_Xml:

Specific webfont providers aside, I think this entire situation makes for //AN_Xml:a fascinating case study of how things can begin to slide if enough small //AN_Xml:mistakes are allowed to consolidate. For me, it was kinda fun to peel back each //AN_Xml:layer and see how it impacted the next part of the problem, and I hope my //AN_Xml:detailing it has taught people a thing or two in the process.

//AN_Xml: //AN_Xml:

If I was to summarise this entire piece with one takeaway, it’s that CSS //AN_Xml:performance is absolutely critical, and with the current trend of overlooking //AN_Xml:and dismissing CSS as its own discipline, cases like this are becoming all too //AN_Xml:common.

//AN_Xml: //AN_Xml:

CSS matters. A lot.

//AN_Xml:

Time to First Byte: What It Is and Why It Matters

Thu, 08 Aug 2019 02:06:56 +0000

I’m working on a client project at the moment and, as they’re an ecommerce site, //AN_Xml:there are a lot of facets of performance I’m keen to look into for them: load //AN_Xml:times are a good start, start render is key for customers who want to see //AN_Xml:information quickly (hint: that’s all of them), and client-specific metrics like //AN_Xml:how quickly did the key product image load? can all provide valuable //AN_Xml:insights.

//AN_Xml: //AN_Xml:

However, one metric I feel that front-end developers overlook all too quickly is //AN_Xml:Time to First Byte (TTFB). This is understandable—forgivable, almost—when you //AN_Xml:consider that TTFB begins to move into back-end territory, but if I was to sum //AN_Xml:up the problem as succinctly as possible, I’d say:

//AN_Xml: //AN_Xml:

While a good TTFB doesn’t necessarily mean you will have a fast website, a bad //AN_Xml:TTFB almost certainly guarantees a slow one.

//AN_Xml: //AN_Xml:

Even though, as a front-end developer, you might not be in the position to make //AN_Xml:improvements to TTFB yourself, it’s important to know that any problems with //AN_Xml:a high TTFB will leave you on the back foot, and any efforts you make to //AN_Xml:optimises images, clear the critical path, and asynchronously load your webfonts //AN_Xml:will all be made in the spirit of playing catchup. That’s not to say that more //AN_Xml:front-end oriented optimisations should be forgone, but there is, unfortunately, //AN_Xml:an air of closing the stable door after the horse has //AN_Xml:bolted. //AN_Xml:You really want to squish those TTFB bugs as soon as you can.

//AN_Xml: //AN_Xml:

What is TTFB?

//AN_Xml: //AN_Xml:

The TTFB timing entry isn’t particularly insightful. View full //AN_Xml:size/quality (375KB)

//AN_Xml: //AN_Xml: //AN_Xml:

TTFB is a little opaque to say the least. It comprises so many different things //AN_Xml:that I often think we tend to just gloss over it. A lot of people surmise that //AN_Xml:TTFB is merely time spent on the server, but that is only a small fraction of //AN_Xml:the true extent of things.

//AN_Xml: //AN_Xml:

The first—and often most surprising for people to learn—thing that I want to //AN_Xml:draw your attention to is that TTFB counts one whole round trip of latency. //AN_Xml:TTFB isn’t just time spent on the server, it is also the time spent getting from //AN_Xml:our device to the sever and back again (carrying, that’s right, the first byte //AN_Xml:of data!).

//AN_Xml: //AN_Xml:

Armed with this knowledge, we can soon understand why TTFB can often increase so //AN_Xml:dramatically on mobile. Surely, you’ve wondered before, the server has no //AN_Xml:idea that I’m on a mobile device—how can it be increasing its TTFB?! The //AN_Xml:reason is because mobile networks are, as a rule, high latency connections. If //AN_Xml:your Round Trip Time (RTT) from your phone to a server and back again is, say, //AN_Xml:250ms, you’ll immediately see a corresponding increase in TTFB.

//AN_Xml: //AN_Xml:

If there is one key thing I’m keen for your to take from this post, its is that //AN_Xml:TTFB is affected by latency.

//AN_Xml: //AN_Xml:

But what else is TTFB? Strap yourself in; here is a non-exhaustive list //AN_Xml:presented in no particular order:

//AN_Xml: //AN_Xml:

Latency: As above, we’re counting a trip out to and a return trip from the //AN_Xml:server. A trip from a device in London to a server in New York has //AN_Xml:a theoretical best-case speed of 28ms over fibre, but this makes lots of very //AN_Xml:optimistic assumptions. Expect closer to //AN_Xml:75ms. //AN_Xml:
- This is why serving your content from a CDN is so important: even in the //AN_Xml:internet age, being geographically closer to your customers is advantageous.
//AN_Xml:
Routing: If you are using a CDN—and you should be!—a customer in Leeds //AN_Xml:might get routed to the MAN //AN_Xml:datacentre //AN_Xml:only to find that the resource they’re requesting isn’t in that //AN_Xml:PoP’s cache. Accordingly, //AN_Xml:they’ll get routed all the way back to your origin server to retrieve it from //AN_Xml:there. If your origin is in, say, Virginia, that’s going to be a large and //AN_Xml:invisible increase in TTFB.
Filesystem reads: The server simply reading static files such as images or //AN_Xml:stylesheets from the filesystem has a cost. It all gets added to your TTFB.
Prioritisation: HTTP/2 has a (re)prioritisation mechanism whereby it may //AN_Xml:choose to stall lower-priority //AN_Xml:responses on the server //AN_Xml:while sending higher-priority responses down the wire. H/2 prioritisation //AN_Xml:issues aside, even when H/2 is running smoothly, these expected delays will //AN_Xml:contribute to your TTFB.
Application runtime: It’s kind of obvious really, but the time it takes to //AN_Xml:run your actual application code is going to be a large contributor to your //AN_Xml:TTFB.
Database queries: Pages that require data from a database will incur //AN_Xml:a cost when searching over it. More TTFB.
API calls: If you need to call any APIs (internal or otherwise) in order //AN_Xml:to populate a page, the overhead will be counted in your TTFB.
Server-Side Rendering: The cost of server-rendering a page could be //AN_Xml:trivial, but it will still contribute to your TTFB.
Cheap hosting: Hosting that is optimised for cost over performance usually //AN_Xml:means you’re sharing a server with any number of other websites, so expect //AN_Xml:degraded server performance which could affect your ability to fulfil //AN_Xml:requests, or may simply mean underpowered hardware trying to run your //AN_Xml:application.
DDoS or heavy load: In a similar vein to the previous point, increased //AN_Xml:load with no way of auto-scaling your application will lead to degraded //AN_Xml:performance where you begin to probe the limits of your infrastructure.
WAFs and load balancers: Services such as web application //AN_Xml:firewalls or load //AN_Xml:balancers that sit in front of your application will also contribute to your //AN_Xml:TTFB.
CDN features: Although a CDN is a huge net win, in certain scenarios, //AN_Xml:their features could lead to additional TTFB. For example, request //AN_Xml:collapsing, //AN_Xml:edge-side includes, etc.).
Last-mile latency: When we think of a computer in London visiting a server //AN_Xml:in New York, we tend to oversimplify that journey quite drastically, almost //AN_Xml:imagining that the two were directly connected. The reality is that there’s //AN_Xml:a much more complex series of intermediaries from our own router to our ISP; //AN_Xml:from a cell tower to an undersea cable. Last mile //AN_Xml:latency deals with the //AN_Xml:disproportionate complexity toward the terminus of a connection.

//AN_Xml: //AN_Xml:

It’s impossible to have a 0ms TTFB, so it’s important to note that the list //AN_Xml:above does not represent things that are necessarily bad or slowing your TTFB //AN_Xml:down. Rather, your TTFB represents any number of the items present above. My aim //AN_Xml:here is not to point fingers at any particular part of the stack, but instead to //AN_Xml:help you understand what exactly TTFB can entail. And with so much potentially //AN_Xml:taking place in our TTFB phase, it’s almost a miracle that websites load at all!

//AN_Xml: //AN_Xml:

So. Much. Stuff!

//AN_Xml: //AN_Xml:

Demystifying TTFB

//AN_Xml: //AN_Xml:

Thankfully, it’s not all so unclear anymore! With a little bit of extra work //AN_Xml:spent implementing the Server Timing //AN_Xml:API, we can begin to measure and surface //AN_Xml:intricate timings to the front-end, allowing web developers to identify and //AN_Xml:debug potential bottlenecks previously obscured from view.

//AN_Xml: //AN_Xml:

The Server Timing API allows developers to augment their responses with an //AN_Xml:additional Server-Timing HTTP header which contains timing information that //AN_Xml:the application has measured itself.

//AN_Xml: //AN_Xml:

This is exactly what we did at BBC iPlayer last year:

//AN_Xml: //AN_Xml:

The newly-available Server-Timing header can be added //AN_Xml:to any response. View full //AN_Xml:size/quality (533KB)

//AN_Xml: //AN_Xml: //AN_Xml:

N.B. Server Timing doesn’t come for free: you need to actually measure the //AN_Xml:aspects listed above yourself and then populate your Server-Timing header with //AN_Xml:the relevant data. All the browser does is display the data in the relevant //AN_Xml:tooling, making it available on the front-end:

//AN_Xml: //AN_Xml:

Now we can see, right there in the browser, how long certain aspects //AN_Xml:of our TTFB took. View full //AN_Xml:size/quality (419KB)

//AN_Xml: //AN_Xml: //AN_Xml:

To help you get started, Christopher Sidebottom wrote up his implementation of //AN_Xml:the Server Timing //AN_Xml:API //AN_Xml:during our time optimising iPlayer.

//AN_Xml: //AN_Xml:

It’s vital that we understand just what TTFB can cover, and just how critical it //AN_Xml:can be to overall performance. TTFB has knock-on effects, which can be a good //AN_Xml:thing or a bad thing depending on whether it’s starting off low or high.

//AN_Xml: //AN_Xml:

If you’re slow out of the gate, you’ll spend the rest of the race playing //AN_Xml:catchup.

//AN_Xml:

Self-Host Your Static Assets

Fri, 31 May 2019 21:10:11 +0000

One of the quickest wins—and one of the first things I recommend my clients //AN_Xml:do—to make websites faster can at first seem counter-intuitive: you should //AN_Xml:self-host all of your static assets, forgoing others’ CDNs/infrastructure. In //AN_Xml:this short and hopefully very straightforward post, I want to outline the //AN_Xml:disadvantages of hosting your static assets ‘off-site’, and the overwhelming //AN_Xml:benefits of hosting them on your own origin.

//AN_Xml: //AN_Xml:

What Am I Talking About?

//AN_Xml: //AN_Xml:

It’s not uncommon for developers to link to static assets such as libraries or //AN_Xml:plugins that are hosted at a public/CDN URL. A classic example is jQuery, that //AN_Xml:we might link to like so:

//AN_Xml: //AN_Xml:

<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"><AN_Scri>

//AN_Xml: //AN_Xml:

There are a number of perceived benefits to doing this, but my aim later in this //AN_Xml:article is to either debunk these claims, or show how other costs vastly //AN_Xml:outweigh them.

//AN_Xml: //AN_Xml:

It’s convenient. It requires very little effort or brainpower to include //AN_Xml:files like this. Copy and paste a line of HTML and you’re done. Easy.
We get access to a CDN. code.jquery.com is served by //AN_Xml:StackPath, a CDN. By linking to //AN_Xml:assets on this origin, we get CDN-quality delivery, free!
Users might already have the file cached. If website-a.com links to //AN_Xml:https://code.jquery.com/jquery-3.3.1.slim.min.js, and a user goes from there //AN_Xml:to website-b.com who also links to //AN_Xml:https://code.jquery.com/jquery-3.3.1.slim.min.js, then the user will already //AN_Xml:have that file in their cache.

//AN_Xml: //AN_Xml:

Risk: Slowdowns and Outages

//AN_Xml: //AN_Xml:

I won’t go into too much detail in this post, because I have a whole //AN_Xml:article //AN_Xml:on the subject of third party resilience and the risks associated with slowdowns //AN_Xml:and outages. Suffice to say, if you have any critical assets served by third //AN_Xml:party providers, and that provider is suffering slowdowns or, heaven forbid, //AN_Xml:outages, it’s pretty bleak news for you. You’re going to suffer, too.

//AN_Xml: //AN_Xml:

If you have any render-blocking CSS or synchronous JS hosted on third party //AN_Xml:domains, go and bring it onto your own infrastructure right now. Critical //AN_Xml:assets are far too valuable to leave on someone else’s servers.

//AN_Xml: //AN_Xml:

Risk: Service Shutdowns

//AN_Xml: //AN_Xml:

A far less common occurrence, but what happens if a provider decides they need //AN_Xml:to shut down the service? This is exactly what Rawgit did //AN_Xml:in October 2018, yet (at the time of writing) a crude GitHub code search still //AN_Xml:yielded over a million //AN_Xml:references to the now-sunset //AN_Xml:service, and almost 20,000 live sites are still linking to it!

//AN_Xml: //AN_Xml:

Many thanks to Paul //AN_Xml:Calvano who very kindly queried //AN_Xml:the HTTPArchive for me.

//AN_Xml: //AN_Xml: //AN_Xml:

Risk: Security Vulnerabilities

//AN_Xml: //AN_Xml:

Another thing to take into consideration is the simple question of trust. If //AN_Xml:we’re bringing content from external sources onto our page, we have to hope that //AN_Xml:the assets that arrive are the ones we were expecting them to be, and that //AN_Xml:they’re doing only what we expected them to do.

//AN_Xml: //AN_Xml:

Imagine the damage that would be caused if someone managed to take control of //AN_Xml:a provider such as code.jquery.com and began serving compromised or malicious //AN_Xml:payloads. It doesn’t bear thinking about!

//AN_Xml: //AN_Xml:

Mitigation: Subresource Integrity

//AN_Xml: //AN_Xml:

To the credit of all of the providers referenced so far in this article, they do //AN_Xml:all make use of Subresource //AN_Xml:Integrity //AN_Xml:(SRI). SRI is a mechanism by which the provider supplies a hash (technically, //AN_Xml:a hash that is then Base64 encoded) of the exact file that you both expect and //AN_Xml:intend to use. The browser can then check that the file you received is indeed //AN_Xml:the one you requested.

//AN_Xml: //AN_Xml:

<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js"
//AN_Xml:        integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8="
//AN_Xml:        crossorigin="anonymous"><AN_Scri>

//AN_Xml: //AN_Xml:

Again, if you absolutely must link to an externally hosted static asset, make //AN_Xml:sure it’s SRI-enabled. You can add SRI yourself using this handy //AN_Xml:generator.

//AN_Xml: //AN_Xml:

Penalty: Network Negotiation

//AN_Xml: //AN_Xml:

One of the biggest and most immediate penalties we pay is the cost of opening //AN_Xml:new TCP connections. Every new origin we need to visit needs a connection //AN_Xml:opening, and that can be very costly: DNS resolution, TCP handshakes, and TLS //AN_Xml:negotiation all add up, and the story gets worse the higher the latency of the //AN_Xml:connection is.

//AN_Xml: //AN_Xml:

I’m going to use an example taken straight from Bootstrap’s own Getting //AN_Xml:Started. They //AN_Xml:instruct users to include these following four files:

//AN_Xml: //AN_Xml:

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="..." crossorigin="anonymous">
//AN_Xml:<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="..." crossorigin="anonymous"><AN_Scri>
//AN_Xml:<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="..." crossorigin="anonymous"><AN_Scri>
//AN_Xml:<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="..." crossorigin="anonymous"><AN_Scri>

//AN_Xml: //AN_Xml:

These four files are hosted across three different origins, so we’re going to //AN_Xml:need to open three TCP connections. How much does that cost?

//AN_Xml: //AN_Xml:

Well, on a reasonably fast connection, hosting these static assets off-site is //AN_Xml:311ms, or 1.65×, slower than hosting them ourselves.

//AN_Xml: //AN_Xml:

By linking to three different origins in order to serve static //AN_Xml:assets, we cumulatively lose a needless 805ms to network negotiation. Full //AN_Xml:test.

//AN_Xml: //AN_Xml: //AN_Xml:

Okay, so not exactly terrifying, but Trainline, a client of mine, found that by //AN_Xml:reducing latency by 300ms, customers spent an extra £8m //AN_Xml:a year. This is //AN_Xml:a pretty quick way to make eight mill.

//AN_Xml: //AN_Xml:

By simply moving our assets onto the host domain, we completely //AN_Xml:remove any extra connection overhead. Full //AN_Xml:test.

//AN_Xml: //AN_Xml: //AN_Xml:

On a slower, higher-latency connection, the story is much, much worse. Over 3G, //AN_Xml:the externally-hosted version comes in at an eye-watering 1.765s slower. //AN_Xml:I thought this was meant to make our site faster?!

//AN_Xml: //AN_Xml:

On a high latency connection, network overhead totals a whopping //AN_Xml:5.037s. All completely avoidable. Full //AN_Xml:test.

//AN_Xml: //AN_Xml: //AN_Xml:

Moving the assets onto our own infrastructure brings load times down from around //AN_Xml:5.4s to just 3.6s.

//AN_Xml: //AN_Xml:

By self-hosting our static assets, we don’t need to open any more //AN_Xml:connections. Full //AN_Xml:test.

//AN_Xml: //AN_Xml: //AN_Xml:

If this isn’t already a compelling enough reason to self-host your static //AN_Xml:assets, I’m not sure what is!

//AN_Xml: //AN_Xml:

Mitigation: `preconnect`

//AN_Xml: //AN_Xml:

Naturally, my whole point here is that you should not host any static assets //AN_Xml:off-site if you’re otherwise able to self-host them. However, if your hands are //AN_Xml:somehow tied, then you can use a preconnect Resource //AN_Xml:Hint //AN_Xml:to preemptively open a TCP connection to the specified origin(s):

//AN_Xml: //AN_Xml:

<head>
//AN_Xml:
//AN_Xml:  ...
//AN_Xml:
//AN_Xml:  <link rel="preconnect" href="https://code.jquery.com" />
//AN_Xml:
//AN_Xml:  ...
//AN_Xml:
//AN_Xml:</head>

//AN_Xml: //AN_Xml:

For bonus points, deploying these as HTTP //AN_Xml:headers //AN_Xml:will be even faster.

//AN_Xml: //AN_Xml:

N.B. Even if you do implement preconnect, you’re still only going to make //AN_Xml:a small dent in your lost time: you still need to open the relevant connections, //AN_Xml:and, especially on high latency connections, it’s unlikely that you’re ever //AN_Xml:going to fully pay off the overhead upfront.

//AN_Xml: //AN_Xml:

Penalty: Loss of Prioritisation

//AN_Xml: //AN_Xml:

The second penalty comes in the form of a protocol-level optimisation that we //AN_Xml:miss out on the moment we split content across domains. If you’re running over //AN_Xml:HTTP/2—which, by now, you should be—you get access to prioritisation. All //AN_Xml:streams (ergo, resources) within the same TCP connection carry a priority, and //AN_Xml:the browser and server work in tandem to build a dependency tree of all of these //AN_Xml:prioritised streams so that we can return critical assets sooner, and perhaps //AN_Xml:delay the delivery of less important ones.

//AN_Xml: //AN_Xml:

To fully understand the benefits of prioritisation, Pat Meenan’s //AN_Xml:post on the topic //AN_Xml:serves as a good primer.

//AN_Xml: //AN_Xml:

N.B. Technically, owing to H/2’s connection //AN_Xml:coalescence, //AN_Xml:requests can be prioritised against each other over different domains as long as //AN_Xml:they share the same IP address.

//AN_Xml: //AN_Xml:

If we split our assets across multiple domains, we have to open up several //AN_Xml:unique TCP connections. We cannot cross-reference any of the priorities within //AN_Xml:these connections, so we lose the ability to deliver assets in a considered and //AN_Xml:well designed manner.

//AN_Xml: //AN_Xml:

Compare the two HTTP/2 dependency trees for both the off-site and self-hosted //AN_Xml:versions respectively:

//AN_Xml: //AN_Xml:

Notice how we need to build new dependency trees per //AN_Xml:origin? Stream IDs 1 and 3 keep reoccurring.

//AN_Xml: //AN_Xml: //AN_Xml:

//AN_Xml: //AN_Xml:

By hosting all content under the same origin, we can build one, more //AN_Xml:complete dependency tree. Every stream has a unique ID as they’re all in the //AN_Xml:same tree.

//AN_Xml: //AN_Xml: //AN_Xml:

Fun fact: Stream IDs with an odd number were initiated by the client; //AN_Xml:those with an even number were initiated by the server. I honestly don’t think //AN_Xml:I’ve ever seen an even-numbered ID in the wild.

//AN_Xml: //AN_Xml:

If we serve as much content as possible from one domain, we can let H/2 do its //AN_Xml:thing and prioritise assets more completely in the hopes of better-timed //AN_Xml:responses.

//AN_Xml: //AN_Xml:

Penalty: Caching

//AN_Xml: //AN_Xml:

By and large, static asset hosts seem to do pretty well at establishing //AN_Xml:long-lived max-age directives. This makes sense, as static assets at versioned //AN_Xml:URLs (as above) will never change. This makes it very safe and sensible to //AN_Xml:enforce a reasonably aggressive cache policy.

//AN_Xml: //AN_Xml:

That said, this isn’t always the case, and by self-hosting your assets you can //AN_Xml:design much more bespoke caching //AN_Xml:strategies.

//AN_Xml: //AN_Xml:

Myth: Cross-Domain Caching

//AN_Xml: //AN_Xml:

A more interesting take is the power of cross-domain caching of assets. That is //AN_Xml:to say, if lots and lots of sites link to the same CDN-hosted version of, say, //AN_Xml:jQuery, then surely users are likely to already have that exact file on their //AN_Xml:machine already? Kinda like peer-to-peer resource sharing. This is one of the //AN_Xml:most common arguments I hear in favour of using a third-party static asset //AN_Xml:provider.

//AN_Xml: //AN_Xml:

Unfortunately, there seems to be no published evidence that backs up these //AN_Xml:claims: there is nothing to suggest that this is indeed the case. Conversely, //AN_Xml:recent //AN_Xml:research //AN_Xml:by Paul Calvano hints that the opposite might //AN_Xml:be the case:

//AN_Xml: //AN_Xml:

//AN_Xml:
There is a significant gap in the 1st vs 3rd party resource age of CSS and web //AN_Xml:fonts. 95% of first party fonts are older than 1 week compared to 50% of 3rd //AN_Xml:party fonts which are less than 1 week old! This makes a strong case for self //AN_Xml:hosting web fonts!
//AN_Xml:

//AN_Xml: //AN_Xml:

In general, third party content seems to be less-well cached than first party //AN_Xml:content.

//AN_Xml: //AN_Xml:

Even more importantly, Safari has completely disabled this //AN_Xml:feature //AN_Xml:for fear of abuse where privacy is concerned, so the shared cache technique //AN_Xml:cannot work for, at the time of writing, 16% of users //AN_Xml:worldwide.

//AN_Xml: //AN_Xml:

In short, although nice in theory, there is no evidence that cross-domain //AN_Xml:caching is in any way effective.

//AN_Xml: //AN_Xml:

Myth: Access to a CDN

//AN_Xml: //AN_Xml:

Another commonly touted benefit of using a static asset provider is that they’re //AN_Xml:likely to be running beefy infrastructure with CDN capabilities: globally //AN_Xml:distributed, scalable, low-latency, high availability.

//AN_Xml: //AN_Xml:

While this is absolutely true, if you care about performance, you should be //AN_Xml:running your own content from a CDN already. With the price of modern hosting //AN_Xml:solutions being what they are (this site is fronted by Cloudflare which is //AN_Xml:free), there’s very little excuse for not serving your own assets from one.

//AN_Xml: //AN_Xml:

Put another way: if you think you need a CDN for your jQuery, you’ll need a CDN //AN_Xml:for everything. Go and get one.

//AN_Xml: //AN_Xml:

Self-Host Your Static Assets

//AN_Xml: //AN_Xml:

There really is very little reason to leave your static assets on anyone else’s //AN_Xml:infrastructure. The perceived benefits are often a myth, and even if they //AN_Xml:weren’t, the trade-offs simply aren’t worth it. Loading assets from multiple //AN_Xml:origins is demonstrably slower. Take ten minutes over the next few days to audit //AN_Xml:your projects, and fetch any off-site static assets under your own control.

//AN_Xml:

Tips for Technical Interviews

Thu, 25 Apr 2019 15:19:18 +0000

Yesterday, I spoke at ITKonket in Kragujevac, Serbia. //AN_Xml:During the Q&A after my talk, one great and non-technical question I got was for //AN_Xml:general advice on interviewing at tech companies. I decided to write down (and //AN_Xml:expand on) my answer in the hope that it might help someone else, too.

//AN_Xml: //AN_Xml:

Disclaimer

//AN_Xml: //AN_Xml:

I don’t claim to be an authority on interviewing.
I don’t think this article is definitive or gospel.
I’ve been self-employed for over five years—I haven’t interviewed for //AN_Xml:a full-time role for a long time.
Your mileage will vary; apply your own context before disagreeing.

//AN_Xml: //AN_Xml:

Preparation – Before the Interview

//AN_Xml: //AN_Xml:

I’d say that solid preparation can carry you through the majority of an //AN_Xml:interview. It helps to quell the nerves, shows that you’re proactive, and gives //AN_Xml:you a head start. Dedicate a lot of time to preparing for interviews.

//AN_Xml: //AN_Xml:

Most prep work will come in the form of asking questions: here are some of the //AN_Xml:most effective ones I’ve used.

//AN_Xml: //AN_Xml:

Who Will be Interviewing Me?

//AN_Xml: //AN_Xml:

This is key, and can really, really help you out. If emails are between you and //AN_Xml:a recruiter, there’s a strong chance that you will not be getting interviewed by //AN_Xml:them. This means that you’ll be going into the interview cold, and your first //AN_Xml:encounter with the interviewer will be live on the night.

//AN_Xml: //AN_Xml:

If this is the case, ask the recruiter who will be interviewing you (you need //AN_Xml:a name and their title). Depending on their answer, there are a few approaches //AN_Xml:to take. Let’s have some example scenarios and how I would handle it.

//AN_Xml: //AN_Xml:

The Head of Technology, Sara Jensen: Right, it’s the big guns. The Head of //AN_Xml:Tech likely reports into C-level staff, so they’ll sit pretty close to the //AN_Xml:business, but might not have as much hands-on technical knowledge as //AN_Xml:a day-to-day engineer. Focus less on technologies and syntax and think more //AN_Xml:about strategic and business-facing case studies from your past.
The Principal Engineer, David Bates: Okay, it’s someone pretty technical; //AN_Xml:someone who writes code on a daily basis. They likely influence and guide //AN_Xml:platform and technical decisions and also hold some seniority. Research the //AN_Xml:team’s stack, and prepare to shoot the sh*t about coding from the trenches.
Front-End Team Lead, Nic Reed; and Head of UX, Preethi Patel: //AN_Xml:Cool, a nice mix. They’re relatively senior, but the fact that design gets //AN_Xml:a representation means that it won’t be a full-on engineering onslaught. //AN_Xml:Familiarise yourself with the product in question, and brush up as much as //AN_Xml:possible or necessary on design fundamentals so as to be as least //AN_Xml:semi-conversant (e.g. suggesting solicited improvements to their onboarding //AN_Xml:flow).

//AN_Xml: //AN_Xml:

Naturally, there could be any mix or cross section of the above, so prepare //AN_Xml:accordingly.

//AN_Xml: //AN_Xml:

Next, ask if it’s possible to get an email intro to the relevant people ahead of //AN_Xml:time as you have some questions for them.

//AN_Xml: //AN_Xml:

Conversely, if you are already emailing with the person who will ultimately //AN_Xml:interview you, you’re pretty well set up—you won’t be going in cold. Use your //AN_Xml:emails to get a sense of the person: are they formal or informal? Do they seem //AN_Xml:hurried? Did they mention an aspect of their personal life (Apologies for the //AN_Xml:delayed reply—I’ve been on holiday over the long weekend.)?

//AN_Xml: //AN_Xml:

You can use these hints to make conversation in the interview, and use them as //AN_Xml:anchors to link back to when making smalltalk (How was your holiday? The //AN_Xml:weather was perfect for it!). Be as personable as possible so that you’re //AN_Xml:already beginning to form a not-purely professional relationship with them. But //AN_Xml:go easy on it. Don’t go Instagram-stalking them or sending them friend requests.

//AN_Xml: //AN_Xml:

Make a good impression. Be interested; be interesting. They’re hiring a human //AN_Xml:being, after all, so use this as an opportunity to differentiate.

//AN_Xml: //AN_Xml:

I’ve Read Your About Page but Is There Anywhere Else I Can Look for a Good Company Overview?

//AN_Xml: //AN_Xml:

This question does a few neat things:

//AN_Xml: //AN_Xml:

It tells them you’ve already read their about page (but you do actually need //AN_Xml:to have read it), so they know you’re taking this seriously and researching //AN_Xml:your prospects individually;
it tells them that you’re keen to know even more if it’s available;
and they spoon-feed your the exact most relevant information for you to get //AN_Xml:a good feel for the organisation. The best info, direct from the source.

//AN_Xml: //AN_Xml:

What Should I Prepare For?

//AN_Xml: //AN_Xml:

Literally ask them how to best prepare for and pass their interview. Will you //AN_Xml:need to bring a laptop? Will you be meeting at their office or an off-site //AN_Xml:location? Do you need to buzz into a shared reception area? Who should you ask //AN_Xml:for upon arrival? Will there be any whiteboarding tasks? What would they like to //AN_Xml:hear from you? Should you prepare a portfolio of work? Do they want to see any //AN_Xml:code you’ve written (if yes, tidy up your repos and check relevant permissions //AN_Xml:for showing code you’ve written elsewhere).

//AN_Xml: //AN_Xml:

Forewarned is forearmed, so ask ask ask. It will leave you better prepared, less //AN_Xml:stressed, and make the interview run more seamlessly.

//AN_Xml: //AN_Xml:

Prepare Your Questions Ahead of Time

//AN_Xml: //AN_Xml:

There’s a real tendency to panic when the interviewer asks And do you have //AN_Xml:any questions for us? It’s all too easy—and common—to hurriedly answer //AN_Xml:Err no yeah everything is great thanks so much!

//AN_Xml: //AN_Xml:

Prepare your questions ahead of time, and ask them confidently. My advice here //AN_Xml:is: buy a nice notepad and a nice pen, assign a fresh double-page specifically //AN_Xml:for the interview, and reserve the left page for notes you take as you chat, and //AN_Xml:on the right-hand side, list each of your questions as a heading under which you //AN_Xml:will write down their answers. Interviews are two-sided, so you need to show //AN_Xml:that you’re taking it seriously. Ask the important questions. Examples are //AN_Xml:coming up later in the post.

//AN_Xml: //AN_Xml:

At the Interview

//AN_Xml: //AN_Xml:

You’re all prepared, you’ve done your homework, and now it’s the big day!

//AN_Xml: //AN_Xml:

Be Personable

//AN_Xml: //AN_Xml:

Arrive ten minutes early. Chat with the receptionist as you wait, make note of //AN_Xml:your surroundings, use it to make small-talk (I love your offices! How long //AN_Xml:have you been in this building?). Make a good impression on everyone you //AN_Xml:encounter—you want everyone to be fighting your corner. If they offer you //AN_Xml:a drink, take them up on it confidently even if you don’t want one. (A black //AN_Xml:coffee would be great, yeah! Thanks!)

//AN_Xml: //AN_Xml:

Use every opportunity to open a dialogue and have a reciprocal experience. //AN_Xml:You’re probably nervous, but do everything in your powers to mask it. Be a good //AN_Xml:person to be around, and make people see you as a potential workmate, not just //AN_Xml:another interviewee.

//AN_Xml: //AN_Xml:

Whiteboarding

//AN_Xml: //AN_Xml:

I hate, hate, hate the performing-monkey, putting-someone-on-the-spot in an //AN_Xml:already stressful situation, distinctly Silicon Valley practice of making //AN_Xml:someone write needlessly complex, already-solved solutions to long-since //AN_Xml:abstracted-away algorithms with a pen. They remind me of the primitive //AN_Xml:hazing techniques that people are put //AN_Xml:through in order to join fraternities: the previous generation watching the //AN_Xml:current generation suffer and squirm because that’s just how it works.

//AN_Xml: //AN_Xml:

But. They’re probably going to happen.

//AN_Xml: //AN_Xml:

To prepare for this, ask before the interview if there will be any whiteboarding //AN_Xml:and what topics might be covered. Read up on a basic working knowledge of the //AN_Xml:topics they list, but don’t devote too much time to memorising the syntax (more //AN_Xml:on that in a second).

//AN_Xml: //AN_Xml:

When the whiteboarding task starts, make a quip or light joke along the lines of //AN_Xml:Oh, wow. I hope you provide full-time staff with computers—I don’t like the //AN_Xml:idea of typing up my handwritten code at home on an evening!. Something like //AN_Xml:this should help to make the situation a little easier, while also gently //AN_Xml:pressing home the sheer ridiculousness of the situation.

//AN_Xml: //AN_Xml:

Honestly, I have such strong opinions about whiteboarding tasks. Oh, //AN_Xml:you’re applying for a job as a chef? Please rear some cattle, invent fire, and //AN_Xml:make us a steak. You may not use any kitchen equipment. We’ll just be stood over //AN_Xml:here. Watching. Judging.

//AN_Xml: //AN_Xml:

Next, before you begin, forewarn them that this is an uncomfortable environment //AN_Xml:in which to ‘write code’; tell them that you intend to annotate any knowledge //AN_Xml:gaps as you go, thus demonstrating that you know you need to look into something //AN_Xml:a little further, but also that you have a vague idea of what that something //AN_Xml:else is.

//AN_Xml: //AN_Xml:

If they’ve refused to give you adequate tooling (i.e. a computer), then you have //AN_Xml:every right to make your own compromises, too: Normally I’d have linting and //AN_Xml:syntax highlighting, etc., so in order to save everyone’s time, I’m going to //AN_Xml:write this out in pseudo-code. Don’t ask if you can write pseudo code: tell //AN_Xml:them that’s how you’re going to approach the task. Regain some of the power.

//AN_Xml: //AN_Xml:

Once you’re done, make sure you’re very aware of any parts you struggled with, //AN_Xml:and be sure to talk through what you would do to fill in those blanks. It’s //AN_Xml:been a while since I implemented x, but I know that the documentation //AN_Xml:covers the exact syntax in detail.

//AN_Xml: //AN_Xml:

Your Questions for Them

//AN_Xml: //AN_Xml:

You’re interviewing them as much as they’re interviewing you, so make sure you //AN_Xml:use your time to get vital insights into the organisation and what you life //AN_Xml:there might look like. As I mentioned earlier, be sure to have these questions //AN_Xml:written down as headings ahead of time. In no particular order:

//AN_Xml: //AN_Xml:

What Might My Average Day Look Like?

//AN_Xml: //AN_Xml:

Honestly, as basic as this question might seem, it’s amazing just how little of //AN_Xml:a role becomes apparent until you’ve started working there—that’s a little too //AN_Xml:late for any surprises. Asking for a rough idea of what your typical day might //AN_Xml:look like forces the interviewer to envisage you successfully in the role, and //AN_Xml:to give deliberate thought to what exactly they will expect of you.

//AN_Xml: //AN_Xml:

This is a good opportunity to catch any unexpected duties that were missing from //AN_Xml:the job spec, and also helps with the first-day nerves of what do I even do //AN_Xml:here?! It makes the role feel a lot more concrete and tangible, and you can //AN_Xml:spend the next few weeks looking forward to life as described to you, rather //AN_Xml:than playing over scenarios in your head.

//AN_Xml: //AN_Xml:

Why Is This Position Available?

//AN_Xml: //AN_Xml:

A very simple but incredibly effective and eyeopening question. If the answer is //AN_Xml:We’re showing really good growth and projections are even healthier, so now //AN_Xml:is time to expand the team a little. We’re adding two new engineers, and //AN_Xml:designer, and a dedicated product owner this quarter then you’re onto good //AN_Xml:news! The company is doing well and you’re about to become part of that journey. //AN_Xml:Share their enthusiasm, congratulate them, and say you’d love to become a part //AN_Xml:of it.

//AN_Xml: //AN_Xml:

If, however, the answer is Our current front-end developer leaves in a month //AN_Xml:and we’re looking to find a replacement. then it’s, unfortunately, a little //AN_Xml:more pessimistic.

//AN_Xml: //AN_Xml:

If you can pluck up the courage, ask why they’re leaving. Answers like She’s //AN_Xml:taking another role at another organisation means that they’ve found //AN_Xml:something that, for whatever reasons, they perceive to be better than the role //AN_Xml:you’re about to adopt. Was it a pay dispute? Was it work-life balance? Was it //AN_Xml:something much more innocuous such as they simply grew tired of a long commute?

//AN_Xml: //AN_Xml:

Where Do I See Myself in Five Years?

//AN_Xml: //AN_Xml:

If anyone asks you the age-old Where do you see yourself in five years? //AN_Xml:question, reply that a large part of that will depend on where the company is in //AN_Xml:four years. If they stay on track and their ethos continues to match your own, //AN_Xml:then great! You’d love to see yourself doing whatever it is you want. But be //AN_Xml:honest with the fact that you would keep a keen eye on the company’s plans and //AN_Xml:form your decisions based a lot on that.

//AN_Xml: //AN_Xml:

How Will My Progress Be Monitored and Fed Back to Me?

//AN_Xml: //AN_Xml:

Once you’re in, who’s keeping an eye on you? How do you know you’re doing the //AN_Xml:right thing? Who’s going to help you progress to the next steps? Will you have //AN_Xml:regular 1:1 meetings at which you can raise any concerns? Will you have any key //AN_Xml:targets against which you will be measured?

//AN_Xml: //AN_Xml:

This is vital, and can raise red flags immediately. I’ve seen too many //AN_Xml:developers fall between the cracks at larger organisations as their individual //AN_Xml:progress is neither monitored or communicated back to them.

//AN_Xml: //AN_Xml:

What Is the Worst Thing About Working Here?

//AN_Xml: //AN_Xml:

If you’re feeling particularly brave—this can be a difficult one to ask—then //AN_Xml:this question is a good way to get a more rounded view of an organisation.

//AN_Xml: //AN_Xml:

As cliche as it may be, it’s not uncommon for interviewers to ask What would //AN_Xml:you say is your greatest weakness? This question is just a slight rewording //AN_Xml:of that.

//AN_Xml: //AN_Xml:

The person interviewing you, unless they’re a founder, is likely a member of //AN_Xml:staff much like you hope to be. They will have their own gripes and annoyances //AN_Xml:with the company, and they may well be comfortable sharing them with. You’re //AN_Xml:unlikely to get brutal honesty, but maybe they’ll give you some insights such //AN_Xml:as working long hours, lack of autonomy, legacy work, etc.

//AN_Xml: //AN_Xml:

If I Have More Questions…

//AN_Xml: //AN_Xml:

A question might spring to mind after the interview has passed, so leave with //AN_Xml:something along the lines of: I appreciate that you’re busy, but if any //AN_Xml:questions spring to mind over the coming days, would it be okay to drop you an //AN_Xml:email with them?

//AN_Xml: //AN_Xml:

Follow Up

//AN_Xml: //AN_Xml:

An appropriate amount of time later (usually the next morning), fire them //AN_Xml:a follow-up email simply thanking them for their time:

//AN_Xml: //AN_Xml:

//AN_Xml:
Hey <name>,
//AN_Xml: //AN_Xml:
You don’t need to reply to this email if you don’t have time, but I just //AN_Xml:wanted to say thanks.
//AN_Xml: //AN_Xml:
I really appreciate your time yesterday—it was really nice to meet you and //AN_Xml:hear more about the challenges at <organisation>. I felt the interview went //AN_Xml:well, and I got a really great feel for the company and the team.
//AN_Xml:

//AN_Xml: //AN_Xml:

//AN_Xml:
If I haven’t heard from you by next Friday, I’ll chase up. Until then, have //AN_Xml:a great week, and I hope <reference to something personable from the //AN_Xml:interview itself>.
//AN_Xml: //AN_Xml:
Speak soon,
//AN_Xml:<name>
//AN_Xml:

//AN_Xml: //AN_Xml:

Polite, to the point, and sets expectations. It also prepares them to hear from //AN_Xml:you, in case they’re the kind of company that is prone to ghosting its //AN_Xml:interviewees.

//AN_Xml: //AN_Xml:

Key Points

//AN_Xml: //AN_Xml:

I guess, in summary,

//AN_Xml: //AN_Xml:

Prepare. It’s all in the preparation.
Be confident, be human.
Ask the right questions and carefully analyse the answers.
Smash it!

//AN_Xml:

CSS Wizardry

Measuring Network Performance in Mobile Safari

Why iOS Gets Overlooked

Why This Is a Problem

Why This Isn’t a Huge Problem

But, Can’t I Just Emulate?

You Will Need…

Testing with WebPageTest

Testing in Safari’s DevTools

Set Your iPhone up as a Development Device

Network Link Conditioner

Enable Web Inspector

Inspect Your Phone From Your Mac

Why Bother?

Site-Speed Topography

Identify Page Types

Gathering Data

Visualising the Data

Building the Map

Final Word

The Fastest Google Fonts

Testing

Default/Legacy

font-display: swap;

Async CSS

preload

preconnect

Bonus: font-display: optional;

Comparisons and Visualisations

Findings

Google Fonts Async Snippet

Real-World Effectiveness of Brotli

Smaller Doesn’t Necessarily Mean Faster

TCP, Packets, and Round Trips

What About the Real World?

Running the Tests

Findings

First-Party vs. Third-Party

Compression Levels

So What?

Performance Budgets, Pragmatically

Targets vs. Safeguards

The Last Two Weeks

Example Performance Budgets

Under Budget

On Budget

Over Budget

Your Turn

Lazy Pre-Browsing with Prefetch

Making Cloud.typography Fast(er)

Solving the Problem for the Client

Need some of the same?

Solving the Problem for Everyone

Reaching Out

The Solution

Closing Thoughts

Time to First Byte: What It Is and Why It Matters

What is TTFB?

Demystifying TTFB

Self-Host Your Static Assets

What Am I Talking About?

Risk: Slowdowns and Outages

Risk: Service Shutdowns

Risk: Security Vulnerabilities

Mitigation: Subresource Integrity

Penalty: Network Negotiation

Mitigation: preconnect

Penalty: Loss of Prioritisation

Penalty: Caching

Myth: Cross-Domain Caching

Myth: Access to a CDN

Self-Host Your Static Assets

Tips for Technical Interviews

Preparation – Before the Interview

Who Will be Interviewing Me?

I’ve Read Your About Page but Is There Anywhere Else I Can Look for a Good Company Overview?

What Should I Prepare For?

Prepare Your Questions Ahead of Time

At the Interview

Be Personable

`font-display: swap;`

`preload`

`preconnect`

Bonus: `font-display: optional;`

Mitigation: `preconnect`