How It Works

The Curious Case of a Comatose Cloud

In learning how remotely hosted images aren’t always all that.

The summary here is that remotely hosting SVGs caused a massive slowdown.

Isn’t the Cloud Magic? Isn’t the Cloud Magic?

Nope. Well. No. It is totally magic, in that they’re great for large files and are an inexpensive storage alternative. But the cloud is, at the end of the day, just another server out there in the world, holding your data. Unless that cloud server is behind a CDN, you may not see a great deal of speed improvements on your site.

And in my case, it didn’t.

Top ↑

Diagnosing the Problem Diagnosing the Problem

In building out a dev site with Tracy (LilJimmi), we noticed certain pages were really slow to load. 35 seconds slow. That’s unacceptable. I compared it to the live site, and it was faster, but some specific pages were still incredibly slow. What pages? The L Word for the most part. And as we inched closer to being done, I said “I’m going to fix this speed stuff before the weekend!” because you can’t go-live on a slow site. You just can’t.

Once I was home, I fired up a local site, installed Query Monitor, and had a serious sit down with everything.

Top ↑

It Wasn’t What I Thought It Wasn’t What I Thought

My initial thought, the one I ruminated on during my bike ride home, was that it was the database queries. Most shows have one or two queer characters, but The L Word has 60 right now. While I may joke about wanting nine more, it’s a weird situation where I need to get the number of characters on the show without knowing the number of characters on the show. My assumption was that it was my calculation loop that caused the issue. That I was querying the queers too many times.

Turned out it wasn’t (just) the number of characters, it was the number of tags.

Top ↑

How It Got So Slow How It Got So Slow

Most of the issue is my fault. Every single tag has a custom image associated with it. These images are stored remotely, in the cloud, and called as part of the design. The issue was that when calling the images I ran a check “Is the service available?” and if not, it would stop. When you make one or two calls, it’s no big deal. When you make a couple hundred, it adds up.

The L Word had 2 icons per 60 characters, and then 15 tags, and then 30 more icons.

Top ↑

Remote Get Is Slow Remote Get Is Slow

I used wp_remote_get to process my images, and it was taking between .1 and .4 seconds per image. That adds up. At first I simplified my check-if-exists routine and more than halved the time to load from 35 to 15 seconds. But in order to drop the page back to 1 second-ish load times, I had to put the images local again. No matter what I did, if I loaded them remotely the best I could get was a 13 second page page load.

Sometimes, local is better.

Top ↑

What’s the moral? What’s the moral?

Obviously the moral is test before you rollout. Which we certainly did! By using Query Monitor, I was able to narrow down the speed for the database queries as well as the speed for all the HTTP requests. In doing so, I lost a CDN but gained speed. I’m trying to figure out how to speed up the CDN, maybe by finding a different front-end proxy, but right now I’ll keep using it for the large files like videos rather than the hundred small ones.

I think it it’s worth it.