I’m like a caveman finding a new shiny pebble.

There’s nothing wrong with the old shiny pebble I’d been enamored with seconds ago, it’s just that … It’s new! Look how shiny it is!

I’ve been experimenting with various methods of cutting this site’s load time, particularly through asynchronously loading blocking files like webfonts and scripts.

I’d been using the Adobe/Google asynchronous font loader, but Adam Beres-Deak’s method became my latest new shiny pebble. His script loader limits the font palette to WOFF and WOFF2 files which have been encoded as base-64 data URIs into an @font-face stylesheet. This loads asynchronously, is added to the head of the page and is saved to local storage rather than being cached.

I use three faces and bold and italic variants of my body type, so it had the advantage of reducing font-related HTTP calls from five to one, even if my overall font file download size stayed roughly the same. I decided to implement it.

As they say on “Top Gear,” how hard can it be?

To create my CSS with data URIs I turned to FontSquirrel’s advanced settings. Subsetting and other cool stuff is available here in a UX that looks like the control panel of a 747.

I ran into problems with FontSquirrel’s base-64 converter, which consistently turns out a CSS file with no embedded base-64 data URIs for WOFF2 files.

A better option, and the one I ended up using, is the Gulp plugin cssBase64, although several other Gulp options are available. FontSquirrel-generated CSS takes a bit of editing to fix font names and properly assign weights and styles. Base-64 is as ugly as a Soviet tractor, so it’s best to not have to go into the output files anyway.

After a couple days of messing with this part in my spare time I had my font files in place. But it still wasn’t working properly due to a slapfight between Safari and Chrome over apparent differing opinions of cross-domain loading.

For various technical reasons I’ll not get into, I was using a full http link instead of a relative path for my font files. Safari treats http://davidputney.com … as cross domain and requires a www for fonts to load. Chrome treats http://www.davidputney.com as cross domain.

It took some time to nail down the problem, but I got it working in both browsers with a somewhat ugly CMS hack that – suddenly stares blankly off into the middle distance – I’ve seen things, man.”

Then my testing revealed another problem: It doesn’t work at all in Safari – desktop or mobile – in private browsing mode.

On the one hand, this site isn’t a porn site. Few will likely ever visit in private mode. But I use private mode on my phone and iPad almost exclusively to defeat site paywalls, so it’s pretty much broken for me on those devices.

I’d be less concerned about this if the effect on site speed wasn’t negligible. Overall load time and render speed are about 1 second faster. But first render is incrementally slower, about .2 to .3 seconds. This pushes first render from a less than a half second to closer to one second.

For most visitors less than a second load time feels immediate, but I’m going for glory on this. Data URIs in general aren’t all that fast. Faster methods appeal to me.

I spent enough time implementing this I want to leave it in place for at least a few days. I’ll weigh the benefits and decide then whether to stick with my new shiny pebble or go back to the old one.