Instantiation

When I give talks or workshops, I sometimes get a bit ranty. One of the richest seams of rantiness comes from me complaining about how we web designers and developers are responsible for making the web a hostile place. “Stop getting the web wrong!” I might shout, like an old man yelling at a cloud. I point to services like Instapaper and Readability and describe their existence as a damning indictment of our work.

Don’t get me wrong—I really like Instapaper, Readability, RSS readers, or any other tools that allow people to read what they want when they want it. But think about their fundamental selling point: get to the content you want without having to wade through the cruft. That cruft was put there by us.

So-called modern web design and development is damage that people have to route around.

(Ooh, I can feel myself coming over all ranty and angry again! Calm down, Jeremy, calm down!)

And. Breathe.

Now there’s a new tool to the add to the list: Facebook Instant. Again, I think it’s actually pretty great that this service exists. But once again, it should make us ashamed of the work we’re collectively producing.

In this case, the service is—somewhat ironically—explicitly touting the performance benefits of not going to a website to read an article. Quite right.

PPK points to tools as the source of the problem and Marco Arment agrees:

The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight.

But I think it’s a bit more subtle than that. As John Gruber says:

Business development deals have created problems that no web developer can solve. There’s no way to make a web page with a full-screen content-obscuring ad anything other than a shitty experience.

Now you might be saying to yourself “Well, I’ve never made a bloated web page!” or “I’ve never slapped loads of intrusive crap over the content!” I’d certainly like to think that I can look at my track record and hold my head up reasonably high. But that doesn’t matter. If the overall perception is that going to a URL to read an article is a pain in the ass, it hurts all of us.

Take this article from M.G. Siegler:

Not only is the web not fast enough for apps, it’s not fast enough for text either. …on mobile, the web browser just isn’t cutting it. … Native apps provide a better user experience on mobile than a web browser.

On the face of it, this is kind of a bizarre claim. After all, there’s nothing inherent in web browsers that makes them slow at rendering text—quite the opposite! And native apps still use HTTP (and often HTML) to fetch content; the network doesn’t suddenly get magically faster just because the piece of software requesting a resource doesn’t happen to be a web browser.

But this conflation of slow websites and slow web browsers is perfectly understandable. If it looks like a slow duck, and it quacks like a slow duck, then why not conclude that ducks are slow? Even if we know that there’s nothing inherently slow about making web pages:

My hope is that Facebook Instant will shake things up a bit. M.G. Siegler again:

At the very least, Facebook has put everyone else on notice. Your content better load fast or you’re screwed. Publication websites have become an absolutely bloated mess. They range from beautiful (The Verge) to atrocious (Bloomberg) to unusable (Forbes). The common denominator: they’re all way too slow.

There needs to be a cultural change in how we approach building for the web. Yes, some of the tools we choose are part of the problem, but the bigger problem is that performance still isn’t being recognised as the most important factor in how people feel about websites (and by extension, the web). This isn’t just a developer issue. It’s a design issue. It’s a UX issue. It’s a business issue. Performance is everybody’s collective responsibility.

I’d better stop now before I start getting all ranty again.

I’ll leave you with some other writings on this topic…

Tim Kadlec talks about choosing performance:

It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

Jim Ray points out that “we learned the wrong lesson from the rise of mobile and the app ecosystem”:

We’ve spent far too long trying to compete with native experiences by making our websites look and behave like apps. This includes not just thousands of lines of JavaScript to mimic native app swipes and scrolling but even the lower overhead aesthetics of fixed position headers and persistent navigation.

(*cough*Flipboard*cough*)

Finally, Baldur Bjarnason has written a terrific piece:

The web doesn’t suck. Your websites suck.

All of your websites suck.

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.

The lousy performance of your websites becomes a defensive moat around Facebook.

Go read the whole thing—it’s terrific:

This is a long-standing debate. Except it’s only long-standing among web developers. Columnists, managers, pundits, and journalists seem to have no interest in understanding the technical foundation of their livelihoods. Instead they are content with assuming that Facebook can somehow magically render HTML over HTTP faster than anybody else and there is nothing anybody can do to make their crap scroll-jacking websites faster. They buy into the myth that the web is incapable of delivering on its core capabilities: delivering hypertext and images quickly to a diverse and connected readership.

Have you published a response to this? :

Responses

Felix Wahner

RT @gurkendoktor: and as I was crafting a blog post, @adactio somehow read my thoughts adactio.com/journal/8956 -it’s our responsibility to keep the web usable

cdevroe.com

Web pages should load quickly May 22, 2015 Facebook’s Instant Articles platform has us web people discussing the speed at which our pages load. It is excellent to see this discussion happening. Here are a few of my favorite tidbits from a few of the pieces I have read recently: Mark Llobrera on A List Apart: That’s my biggest takeaway from Instant Articles: we (designers and our clients) have to start tasting our work. Not just in our proverbial kitchen, but where our users actually eat the stuff. Jeremy Keith on his blog: There needs to be a cultural change in how we approach building for the web. Yes, some of the tools we choose are part of the problem, but the bigger problem is that performance still isn’t being recognised as the most important factor in how people feel about websites (and by extension, the web). This isn’t just a developer issue. It’s a design issue. It’s a UX issue. It’s a business issue. Performance is everybody’s collective responsibility. Jeffery Zeldman on the A List Apart blog: Soon, driven by fear that apps would make the web irrelevant, we began relying on frameworks that made even the simplest website act and feel like a mind-blowing application. Serving reams of code we didn’t need because, hell, it came with the frameworks, and abandoning principles like progressive enhancement because, hell, everybody uses JavaScript, we soon fell in love with high-resolution, full-screen background images, then fell even harder when those images quadrupled in weight thanks to Retina. I’m as guilty as anyone. Perhaps even moreso since I work on a tool that allows people to edit web pages. However, this recent discussion has me rethinking and retooling. I’m excited to see the web get faster as a result of this push. View all posts

# Monday, April 23rd, 2018 at 8:20pm

4 Likes

# Liked by Faruk Ateş on Wednesday, May 20th, 2015 at 7:22pm

# Liked by Dan Boulet on Thursday, May 21st, 2015 at 6:16am

# Liked by Mary Trigiani on Thursday, May 21st, 2015 at 8:23am

# Liked by Remy Bernstein on Wednesday, May 27th, 2015 at 4:30pm

Related posts

Speedier tunes

Improving performance with containment.

Speedy tunes

Improving performance on The Session.

The intersectionality of web performance

Business, sustainability, and inclusivity.

Doing the right thing for the wrong reasons

Speak softly and carry a big Google stick.

Portals and giant carousels

Trying to understand why people think they need to make single page apps.

Related links

Let websites framebust out of native apps | Holovaty.com

Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:

Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.

Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:

The more I think about it, the more I cannot believe webviews with unfettered JavaScript access to third-party websites ever became a legitimate, accepted technology. It’s bad for users, and it’s bad for websites.

By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.

Tagged with

Against an Increasingly User-Hostile Web - Neustadt.fr

With echoes of Anil Dash’s The Web We Lost, this essay is a timely reminder—with practical advice—for we designers and developers who are making the web …and betraying its users.

You see, the web wasn’t meant to be a gated community. It’s actually pretty simple.

A web server, a public address and an HTML file are all that you need to share your thoughts (or indeed, art, sound or software) with anyone in the world. No authority from which to seek approval, no editorial board, no publisher. No content policy, no dependence on a third party startup that might fold in three years to begin a new adventure.

That’s what the web makes possible. It’s friendship over hyperlink, knowledge over the network, romance over HTTP.

Tagged with

From WordPress to Apple News, Instant Articles, and AMP - The Media Temple Blog

Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.

Hey, whatever you want. As long as…

  1. It’s not very much work
  2. The content’s canonical home is my website.

I just want people to read and like CSS-Tricks.

Tagged with

Don’t Forget The Web

Here’s the video of the talk I gave at Facebook’s Mobile @Scale event where I was the token web guy. The talk is pretty short but there’s some fun Q&A afterwards.

Tagged with

Rise of the meta-platforms and the new ‘web browser’ - Tales of a Developer Advocate

Paul compares publishing on the web to publish on proprietary platforms, and concludes that things aren’t looking great right now.

Performance is the number one selling point for each of these new content platforms.

Tagged with

Previously on this day

16 years ago I wrote You are iPlayer

This URL will self-destruct in seven days.

17 years ago I wrote Sliding away

Before I head off for my next presentation, here are some slides I prepared earlier.

18 years ago I wrote Ex-tech

The XTech 2006 conference provided plenty of food for thought.

21 years ago I wrote SkillSwapping

I gave my SkillSwap talk on CSS based design last night. I had been preparing for it for a while which is why my journal entries have been somewhat sporadic of late.

22 years ago I wrote This really, REALLY! stank

3 Stench Ridden Days…

22 years ago I wrote Building a Life-size Millennium Falcon

The Online Documentary: