I recently made a pretty heavy shift over to Cloudflare. The majority of assets and HTML on this site load from Cloudflare’s servers now, instead of my own. The only time this differs is when I push changes up to its GitHub repo. The last step in the build process after deploying to my server is hitting the API and requesting a complete cache dump. I could be more programmatic about it but updates aren’t frequent enough to warrant a more careful approach.

On its own, Cloudflare’s caching and CDN is great, but there’s another piece that makes it even better. Argo is Cloudflare’s smart routing feature that makes real-time choices about the best path to take from the Cloudflare POP (point of presence) to the origin (my server). This can dramatically reduce requests that do have to make their way to my San Francisco-located server.

It’s $5 a month plus $.10 per GB. Since most of the content on this site is text and a smattering of images, I’m not concerned with the price and $5 is fun money, basically. I saved that moving from DNSimple to Cloudflare for DNS, too, so there’s that.

Looking at some of the stats, now…

As reported by Updown.io (the service that powers status.johnathan.org and the uptime percentage at the bottom of the page), the majority of my requests come in in no time at all, with the obvious winner being Los Angeles (closest to San Francisco, my DigitalOcean location). The outlier is France, though I’m not too concerned with it. It seems to be fluctuating.

Moving over to Pingdom…

It’s pretty obvious when Argo was enabled. I’m not sure what happened with the spike half-way between the 16th and 17th, but a response time being cut in half is amazing, even after doing zero work on the server, itself.

Lastly, the Cloudflare stats…

We see a clear difference in their metrics of response time improvements. Including the entire TLS handshake process, these sub 200ms response times in most cases is wonderful. At scale, Argo would have the potential to be mind-numbingly fast.

I’ll continue to use Argo for the foreseeable future. Cloudflare is free and works great for hobbyists like myself. Argo is $5 + $0.10/GB and I’d consider that peanuts. If it’s of any help, I’ve sent maybe 50MB through it since I signed up a week ago (remember, mostly text and a few images).

It was only a matter of time before someone wielded a class-action lawsuit and charged after Apple:

The suit alleges repeatedly that Apple “promoted and sold laptops it knew were defective in that they contain a keyboard that is substantially certain to fail prematurely,” and that selling these computers not only directly to its customers but also to third party retailers constitutes a violation of good faith. The plaintiffs are seeking damages and legal fees, and demand that Apple admit to the design flaw and cover all costs for remedying or replacing the defective computers. The full class action complaint is embedded below.

I’m shocked, shocked I tell you!

Seriously, though, on the surface, it’s hard to argue that Apple didn’t know the keyboards were a problem. They first made an appearance on the 12” MacBook, the ultra-thin one-port metal slab, a few years ago. After making their way to the MacBook Pro 13” and 15”, some tweaks were made to key travel but largely stayed the same.

The best outcome I see here is a settlement for a small handful of dollars per person. A recall won’t fix the problem unless Apple has an entirely new keyboard they can slot into place. If that’s the case, one could reasonably wonder why Apple didn’t come out and say they have a fix (that new keyboard)?

Beyond all this, though, I won’t be surprised if the whole debacle ends up being a side-note at WWDC. Apple wouldn’t admit they screwed up on a public stage like that. Jony Ive wouldn’t let that happen.

You can read the entire lawsuit here.

Something I’ve wanted to touch on ever since a couple posts ago was lazy loading images. Now that I’m trying to consciously serve 2x images for those with such a pixel density, I’m setting myself up for increased page loads and folks may never even make it that far down the page. Since there’s no need to load what one won’t see, I set out to add lazy image loading support to the blog.

This really doesn’t apply specifically to Jekyll, in fact there’s nothing about this that’s unique to Jekyll but during my searches, I initially felt I needed to find a Jekyll plugin to solve this problem. Since I had that idea, I’m certain others will, too, so I want to catch as many of those folks as I can and let them know it’s easier than that!

As far as the JavaScript goes, I’m using the vanilla-JavaScript-based lazyload.js. I just need to toss it into the footer (no point in loading it before everything else, which technically means we’re lazy-loading the lazy-loader):

<script>
  (function(w, d){
	var b = d.getElementsByTagName('body')[0];
	var s = d.createElement("script"); s.async = true;
	var v = !("IntersectionObserver" in w) ? "8.7.1" : "10.5.2";
	s.src = "https://cdnjs.cloudflare.com/ajax/libs/vanilla-lazyload/" + v + "/lazyload.min.js";
	w.lazyLoadOptions = {}; // Your options here. See "recipes" for more information about async.
	b.appendChild(s);
}(window, document));
</script>

What we’re doing here (courtesy of the lazyload.js documentation) is selecting the best version of it based on the browser. Version 8.x plays better with everything and since not all browsers support IntersectionObserver, it’s important to be backwards compatible. Version 10.x will load for Firefox, Chrome and Edge, while 8.x will load for pretty much everything else.

Now that our JavaScript is in play, the only other step is to update the image tags. I have a TextExpander snippet to help me out here, since I’m also inserting retina (@2x) images. It looks like this:

[![](){: data-src="%filltext:name=1x image%" data-srcset="%filltext:name=2x field% 2x" data-proofer-ignore}](%filltext:name=full image%){: data-lightbox="%filltext:name=lightbox tag%"}

This creates four fields, the paths to the 1x small image 2x small image, the full-size image loaded and the tag needed by lightbox.js. The finished markdown product looks like this (taken from a previous post):

[![](){: data-src="/assets/images/2018/05/07/gtmetrix-0512-sm.jpg" data-srcset="/assets/images/2018/05/07/[email protected] 2x"}](/assets/images/2018/05/07/gtmetrix-0512.jpg){: data-lightbox="image-3"}

Pretty slick, eh? With this in place, some bytes will be saved every day.

You might have noticed the data-proofer-ignore attribute. That’s to keep htmlproofer from tripping over these images because they have no src or srcset attributes defined. It’ll essentially skip them during its check. The downside is if I need to do an audit on images, I’ll have to bulk eliminate data-proofer-ignore at least temporarily.

Once this is all said and done, let the better test results come pouring in!