TheOverAnalyzed

This is the second post in a series called Ditching Webfonts. If you haven’t already done so, you should read the first post in this series. You can also read the final post in the series.

Becoming Ideal ¶

Ever since I became more interested in typefaces and web design, Ideal Sans had been my unicorn. When I initially became interested in using that font on my website, I knew very little about HTML and CSS, or webfonts in general. Because of that, I wasn’t sure how to add it to my website. All I knew was that I liked it. Marco used it for his blog and app, and Q Branch used it for Vesper. It’s also available in the Feedbin webapp (along with other Hoefler originals like Whitney).

When I moved from Squarespace to Camel last month, one of the lights at the end of the tunnel was securing Ideal Sans for the website. I remember the first time I deployed my site and I saw that beautiful and personable typeface staring right back at me. What joy.

I had done it. I made my own website. And I made it look good.

Settling On Ideal ¶

Over the course of the next few weeks, I was constantly tweaking this and that in CSS.^[1] Up until a few days ago, page load times were a rather trivial matter for me. From the beginning, I knew there would be no way to match John Gruber’s lightning-quick Daring Fireball, which loads in approximately 1 second on desktop and mobile.

Gruber has virtually no JavaScript extensions in use, and his website rarely features an embedded image. When it does, the size of the image is in the low hundred of kilobytes. Conversely, TheOverAnalyzed has always been a media-rich blog. I don’t just write about Apple. Very often, pop culture posts can be found interspersed amongst the posts about static blogging engines and other such nerdery. And when I do write about something like Star Wars or movies, the posts usually include a picture or two. Also, because of the way the Camel handles pagination, the homepage and each subsequent page might have 10-15 posts, depending on my post/day ratio. If each posts has one picture weighing in around 500 KB, that could add up to around 7-8 MB for each index page.

Thus, Daring Fireball this is not. And there really isn’t anything wrong with that.

Still, ever the tinkerer, I was am always tweaking this or that, testing local versions of the site against certain JavaScript and jQuery plugins. The goal is always the same: try to make TheOverAnalyzed faster. I eventually settled on a middle ground. I could deploy TheOverAnalyzed with Ideal Sans, Bigfoot footnotes, and auto-width YouTube embeds for around 2.5 seconds of page loading. Certainly not as fast as Daring Fireball, but fast enough.

Right?

The Slow Web ¶

My priorities changed somewhat last week. Gruber wrote a short piece on the crummy state of modern web browsing, focusing primarily on how slowly most webpages load these days. According to Gruber, the culprit was all those JavaScript extensions powering those annoying web advertisements. He picked on iMore in particular. I did the same.

While I was writing that post last week, I experimented with a jQuery plugin called Lazy Load, by Mika Tuupola. The purpose of that plugin is to prevent the loading of embedded images until they come into viewport. I had to edit the source code (Markdown/HTML) for my posts by adding a special class to images, <img class="lazy", as well as add a data-original= modifier in place of the traditional src=. When the image comes into focus on the webpage, Lazy Load dynamically reads the data-original= content and inserts an src= string into the <img> tag, thereby loading the image. It’s a pretty nifty plugin—at least in theory.

Truthfully, I’m not sure why I was so bent on trying this. At the time, I justified using it by telling myself that it would make TheOverAnalyzed load faster. From the beginning, this was flawed logic. Previously, I tested the site against the Disable Images option in Safari’s Develop menu. And guess what? Disabling images never made a meaningful difference in page loading times.

But I tried Lazy Load anyways. Funnily enough, the deployment of the site that contained my aforementioned post on slow-loading webpages coincided with my trying Lazy Load full-tilt. And guess what? It actually increased the page loading of TheOverAnalyzed! Yes, while my ‘holier than thou’ post was being propagated to FeedPress and social media, my site was all the while slower than before I wrote my post. How ironic.

How is it possible that a plugin designed to speed page loading could actually make my site slower? I’m not sure I know exactly why. My working theory is that on a page with a bunch of images (15-20 on the homepage at the moment), the client-side JavaScript compiler is doing a lot of work to parse the Lazy Load script. Also, I wasn’t able to perfect the placeholder image syntax. And because of that, every time Lazy Load inserted the src= string, the layout of the page was modified. That couldn’t have been healthy for page loading speeds. This was especially apparent on mobile, where the page loading time increased from around 2.5 seconds to 5 seconds. That is a long time to wait for a page to load. I can’t imagine why anyone would stick around that long to wait for my homepage to generate.

Less than an hour after that deploy, I had re-edited my posts to remove the Lazy Load image classes and attributes, and I had completely removed the plugin from TheOverAnalyzed. So then: back to square one.

Trying Stuff ¶

Yesterday, I experimented more with disabling JavaScript. Without JavaScript enabled, page load times were only marginally faster. And as I said previously, gaining less than a quarter second in page loading times didn’t warrant losing Bigfoot footnotes. But while I was experimenting in Safari’s View Page Source window, I noticed something. In general, TheOverAnalyzed initializes rather quickly, somewhere in the range of 100ms. However, immediately thereafter—before loading the next resource—there was latency of around 800ms. That next resource I speak of is the Ideal Sans webfont, served up via Hoefler & Co’s Cloud.typography backend.

800ms. That’s almost an entire second of latency. And Ideal Sans—my favorite font—was the culprit.

Could I fix this?

Considering The Inconsiderable ¶

Interestingly, while I was examining TheOverAnalyzed’s page source and realizing that the Hoefler webfont was killing my page loading, an important conversation was happening on Twitter.

@benthompson No one should ever do anything that makes a website slow.

— John Gruber (@gruber) July 14, 2015

@marcoarment @benthompson That’s one reason I’ve procrastinated on switching to webfonts at DF. (Bigger reason: inertia.)

— John Gruber (@gruber) July 14, 2015

Moreover, it seems Craig Hockenberry has experienced (or at least has knowledge of) webfont latency for himself:

@jimray @gruber @marcoarment @benthompson They can have high latency depending on where they’re hosted.

— Craig Hockenberry (@chockenberry) July 15, 2015

If Ideal Sans was the problem, I wondered how fast TheOverAnalyzed would load without it?

Gaining A Second ¶

To test the site without the webfont, I modified styles.css, so that there would be a fallback font. In this case, Avenir, which is like Helvetica but less cliche.^[2]

I also commented-out the stylesheet helper for the webfont in the <head> section (header.html for Camel)

Once that was done, the results were noticeable.

Yes, still not Daring Fireball, but significantly quicker page loading without the Cloud.typography latency.

Slow Is Death ¶

Ben Thompson of Stratechery recently wrote on the subject of web advertisements from the perspective of both the publishers and the readers. Always the pragmatist, he had this to say:

The problem for publishers, though, is that dollars and cents — which come from advertisers — are a far more scarce resource than are page views, leaving publishers with a binary choice: provide a great user experience and go out of business, or muddle along with all of the baggage that relying on advertising networks entails.

He also puts the slow web conversation into perspective with regard to Facebook Instant Articles:

If the New York Times cannot resist programmatic advertising, what chance does iMore or the vast majority of online publications have? If anything this puts Facebook’s Instant Articles initiative in a far more positive light: the social network is offering to not only improve the user experience by displaying articles instantly — thanks, primarily, to the lack of programmatic advertising cruft — but also to help monetize said content by selling ads against it and sharing 70%, backed by profile data that is far superior to even the ad networks.

Indeed, arguably the biggest takeaway should be that the chief objection to Facebook’s offer — that publishers are giving up their independence — is a red herring. Publishers are already slaves to the ad networks [emphasis added], and their primary decision at this point is which master — ad networks or Facebook — is preferable? [A reckoning is coming], as I noted when Facebook’s Instant Articles launched. The future for most publishers is likely that of pure content production only, save for the few — like Gruber — who are destination sites capable of selling native advertising in stream (or selling subscriptions, like this site). What is very much in question is exactly how users will feel when they finally get what they claim they wish for.

Ben Thompson is coming at slow loading webpages from a different perspective than me. The point of his post was to explain how iMore’s job of making a Gruber-approved webpage is easier said than done. Because the average web reader is not willing to pay for content, ads must be served to keep the publisher publishing. And, as Thompson asserts, users can’t have free without ads. For both the publisher and the reader, Facebook Instant Articles (and Apple News) might not be that bad after all, on an infinite time scale.^[3]

Now What ¶

My webpage wasn’t slow because of horrible JavaScript-powered advertisements like what plagues iMore. TheOverAnalyzed was slow because of a webfont. But the difference isn’t what’s important. The end result is. Slow-loading pages are problematic for both publishers and readers. I’m sure publishers wished their websites were better, just as I’m sure readers wish websites were better. For myself and TheOverAnalyzed: as long as webfonts are slow, I can’t imagine I’ll be coming back.

Still, I am not sure if I’ll stay away from webfonts forever. I haven’t taken a serious look at Adobe’s Typekit or Google Fonts, because neither one offered Ideal Sans. I might experiment with those services in the future. For now, however, I think I’ll be okay with Avenir. It’s no Ideal Sans, but it sure beats Helvetica.

And because I’m in the purging mood, I’m going to try TheOverAnalyzed without all JavaScript as well.^[4] I’ll probably turn it back on, but I want to enjoy speedy page loads to the fullest extent possible. I’ve always wondered why Daring Fireball didn’t have any fancy JavaScript. Now I know why. Because it’s faster without it. And for the web, faster is always better.