ponyfoo.com

Priorities

Fix

Peter-Paul Koch (@ppk) recently wrote an article that generated noticeable turmoil. One of the best responses was Jeremy Keith (@adactio)'s article, “Instantiation”, where he graced us with a flurry of responses from different bloggers, as well as a timeline and his analysis of the situation as a whole.

Earlier today, @ppk published a follow-up post, where he mentioned Tim Kadlec (@tkadlec)'s article on “Choosing Performance”. Tim rightly asserts that the web is not inherently slow, and that if a site is slow it’s merely due to the fact that performance wasn’t prioritized by the site’s maintainers. Similarly, Jeremy posited that services such as Instapaper or Pocket shouldn’t have a reason to exist. Besides being well-designed products that many of us use and love, that shouldn’t be the case, websites should offer that degree of usability, and accessibility on their own, Jeremy argues.

content.png
content.png

What if we were to focus just on the content? Are any prominent “apps” as ad-dollar hungry as the screenshot above?

Everyone seems to agree that the crux of the issue stems from media deals and dollar-hungry marketers who have little interest in much else than profits. I tend to agree with that view. Most consumer-facing media rely directly on ad revenue, have little to no regard for their typical user when it comes to the effects these ads have on their experience (hey, we call them “users” for a reason, right?), and simply keep on piling on advertisement.

Sure. There’s definitely some excellent original work in there — in the middle of all those ads and self-links and chrome and value-added “journalism.”

I don’t see this trend being anywhere close to slowing down, quite the contrary. Video advertising is becoming more and more prominent, huge unoptimized hero images and annoying interstitial dialogs that want you to download a mobile app that’s supposed to do what the site you’re already on should be doing, along with ridiculous laws, are all becoming lingua franca in web publishing.

All of this wouldn’t affect us as web workers if it weren’t for the fact that all the extra cruft is being blamed on the web platform itself, as @ppk and @tkadlec point out. It’s not even just the bloat, but we also keep on breaking the web by trying to mimic mobile applications, in one of those desperate attempts to become successful by imitating aspects of a business (e.g Google’s 80-20 rule) that have very little to do with their actual success. Scrolljacking, irritating banners that only frustrate the hell out of users who don’t want to install your app for no good reason, and similar tactics to drive mobile app usage have done nothing but hurt.

It’s time for the web to step up.

allthingsdigital.png
allthingsdigital.png

There’s always been a long-standing fallacy that sites must look the same on every browser. Maybe that’s the reason why it took us so very long to adopt responsive web design. It may be here, at the intersection between design/UX and performance, that we may find our answers. After all, if you look to the corners of the web that actually care about both parties, their web experiences are largely as enjoyable as their mobile counterparts. See Twitter or The Guardian for reference.

Everything is relative. It’s all about context. It’s all about priorities. In the world of development, it’s all about productivity. We seem to be perfectly okay with disregarding performance in favor of productivity. On the surface, this is reasonable, nobody in their right mind would choose Assembler over JavaScript because of performance, right? Well, yes. But we also have to draw a line at some point. If slow sites take 8 seconds to load, and Facebook can bring that down to “zero” by prefetching and whatnot, that’s great, from Facebook’s business point of view.

facebookinstant.png
facebookinstant.png

Not even a minute for the landing page of a marketing microsite, not bad! (I’m on a hotel’s wi-fi in Australia, but that shouldn’t be a huge deal, right?)

Except no reasonable site should ever take 8 seconds to get to their content. I’ve recently gave a talk on the performance optimization subject at CampJS, and here’s my talk slides. I’ve also compiled the talk down into a self-guided workshop called perfschool, with ten different exercises, that I encourage you to try and walk through from the comfort of your home. If you still think you can’t get your site to be drastically faster, I encourage you to check out the content churned by all of the authors I’ve mentioned above, since they care about performance quite a bit and they always produce quality articles that result in actionable performance gains. @scottjehl, @paul_irish, @addyosmani, and @igrigorik are also some other people to track in terms of better understanding performance, and also have a solid grasp on user experience and design.

There’s dozens of web specification drafts being worked on, and the fact that the web is the largest available runtime doesn’t quite make it a piece of cake to quickly churn out updates – the rate at which innovation on the web is occurring, regardless, is nothing short of astonishing.

Changing the public’s perception on the web being inherently slow is going to be a long and winding road. Most of the way, though, it’s going to be about not comparing the web to mobile anymore. It’s not like Facebook Instant Articles or mobile apps do anything fundamentally different than relying heavily on the web to operate. The same web we’ve already wrote off as “too slow to be in the picture”.

The best ways of improving the situation, as well eventually come to see, are to go back to the server, adjust UX for humans, measuring performance, optimizing the critical rendering path, following style guides, and writing all the modules.

Content is king. Defer the rest, and stop breaking the web.

Liked the article? Subscribe below to get an email when new articles come out! Also, follow @ponyfoo on Twitter and @ponyfoo on Facebook.
One-click unsubscribe, anytime. Learn more.

Comments (2)

Harry wrote

Thanks for your article and the work on perfschool. Unfortunately the npm install didn’t work for me at all. My first error was something about phyton missing in the os path - so phyton is a required dependency? Maybe a short information about the dependencies (there seems to be a lot of them!) would be helpful. In my next tries I got several “ENOENT lstat” errors, which could not be resolved with “npm cache clean”. So finally I gave up, maybe I try it again later.

Nicolas Bevacqua wrote

It’s not that perfschool depends on Python, but there’s things like gm that do. If you want you can post an issue on perfschool on GitHub, but the issues you’re having are due to the underlying dependencies, not perfschool itself