Nick Heer has a comprehensive post on how web pages have become so slow despite huge improvements in our internet speeds. He covers JavaScript tracking, Google’s AMP, and a CNN web page that takes 30 seconds to load:
The vast majority of these resources are not directly related to the information on the page, and I’m including advertising. Many of the scripts that were loaded are purely for surveillance purposes: self-hosted analytics, of which there are several examples; various third-party analytics firms like Salesforce, Chartbeat, and Optimizely; and social network sharing widgets. They churn through CPU cycles and cause my six-year-old computer to cry out in pain and fury. I’m not asking much of it; I have opened a text-based document on the web.
As a contrast, consider my blog post from yesterday. All requests for the page (1 for HTML, 3 for CSS files, and an image) total only 34 K. The page loads completely in 1/3 of a second.
This is how most web pages should be. Lightweight, fast. It’s how all Micro.blog-hosted sites are designed. If you’ve let your blog become too bloated with JavaScript includes or images, it’s worth some time to trim out extra resources that don’t really matter.
Eli Mellen @cm This is really nice to see (also looks like a great conference). I recently watched a talk (which I don't seem able to find at the moment) where one of the leads behing PHP talked about a major focus in refactoring and improving PHP7 and beyond is to increase energy efficiency for exactly these reasons.
Manton Reece @cm Framing it around sustainability makes sense to me. So many web pages now are just wasteful: to both our time and computing resources.
Simon Woods My move to Firefox was odd timing, considering this has just come up (again). Hopefully Mozilla continues to press hard on their messages around an open, sustainable web; giving everybody an alternative option when it comes to web browsing is only a good thing.
I knew the web initially mostly from message boards and the number of "runs best on X browser" messages are burned into my mind. Seems like we're headed that way again, an inevitable progression considering how much power Google has consolidated as both vendor and provider.
Mark McElroy This post and other conversations here are making me rethink my own blogging practices. I've taken pride in offering big, gorgeous photos (and I profit more than I would ever have expected to from well-placed, unobtruisive ads in sidebars), but I'm realizing that I've been posting less because of all the overhead now associated with my process. The idea of a fast, simple site really appeals to me.
Paul Robert Lloyd Funnily enough, I was looking at the performance of micro.blog hosted sites just yesterday. While this is a good start, there’s plenty of room for improvement, with caching of static assets being high on the list. www.webpagetest.org/result/18...
Manton Reece @paulrobertlloyd Interesting, thanks for sharing that. I actually don't want to use a CDN because I think all the photos you upload should be at your own domain name. (The only exception is the profile photo, which is served from Micro.blog and actually could be faster.)
Manton Reece @markmcelroy Yeah, making it as simple as possible to post is definitely one of the goals with Micro.blog. If blogging is easier, more people will do it.
Eli Mellen @paulrobertlloyd a CDN isn't needed to meet many of these improvements. Most of the caching needes could be met with .htaccess rules. I don't use a CDN on my site, by have all the images configured to cache (granted, that means folks visiting my site get to cache a bunch of images...since I post a lot of images 🤷)
Paul Robert Lloyd Agreed – although it might be possible to use a CDN behind the scenes while also respecting custom domains. Compression and caching are certainly worth investigating however; pretty much the first performance dial to turn when optimising a website. By means of comparison, here is a report for a post on my site: www.webpagetest.org/result/18...
Manton Reece @eli @paulrobertlloyd The browser will do some basic caching of most of the photos. The biggest hit is the profile photo which takes a couple round-trips through my servers. But it's kind of theoretical because my site loads in 200 ms already.
Eli Mellen on a similar note I’ve noticed that profile photos are broken for me when I view folks’ hosted sites. Is this a known issue? I’d be happy to do more digging if that would be helpful.
Manton Reece @eli Definitely send an example. Looks good on a few sites I just tested.
Paul Robert Lloyd It will, but without a max-age or expires value, revisting the site will see the same asset get downloaded again – behaviour I’ve noticed on the micro.blog timeline too, in fact.
Manton Reece @paulrobertlloyd People can always use Cloudflare with Micro.blog too if they want it. I care more about the real-world performance than what a report might suggest... Compressing a file that is only 5 KB isn't going to help. (I would like to make profile photos faster and cached, though.)
Eli Mellen I did a little bit of digging -- it looks like Privacy badger was the culprit. Turning it off solved the issue. Interesting that it only inteferes with micro.blog user icons when served to a hosted blog. No problem anywhere else, nor with any other images.
Simon Woods @eli I previously had issues with Privacy Badger. Looks like it remains a thoroughly aggressive option, although I think my problem was to do with how it was blacklisting WordPress.