Your login functionality is a feature. Your social sharing buttons are
features. Your core product offering itself has who-knows-how-many features. But what about your website’s speed? Given that research has shown slow website speed, (whatever slow might mean to some users), can hurt you in terms of abandonment and lost sales when there’s any sales involved, shouldn’t speed be considered a feature? That is, maybe website load time shouldn’t be just a “tech thing” that kind of gets done as a matter of course. Rather, it should be a core measurement given that it’s demonstrably a driver of other Key Performance Indicators. (KPIs.)
How bad is the problem?
Following are a couple versions of a chat about Speed I put together for a Udemy.com course I built for Digital Product Management. The ideas are so important though, I’ve extracted these as free segments because the more people that spread this word the better.
SlideShare Version
YouTube Version
How Did We Get Here?
Many moons ago, I worked for one of the earlier consumer online services. It was called Prodigy Services Company and arguably started the mass market towards the online world. Yes, there were others out there and you could buy expensive modems to get access to online services, but Prodigy once-upon-a-time made a massive investment in seeding the marketplace with relatively inexpensive modems to allow the first mass market consumers to come online. Details on what happened next have been written about by plenty of others, but the core thing at issue for my point here is the next step was that, at that time, byte count and speed was hugely critical due to inherently slow speed of page delivery infrastructure. (We’ll leave aside the weak graphics treatment of the time and so on.) Demand eventually brought us to widespread adoption and eventual broadband. Which at first was the wild west of Yee Haw, load up them thar’ graphics paw, we got us some BROADBAND! Toss some more ads on that page too! And code! Oh… oh… yeah baby! I’ll take TWO JavaScripts please. And let’s see… three PHP functions… and… and… oh, gimme some kind of frameworks on top of that. No, don’t worry about asymmetric loading. Puh-lenty of room in the pipe!
So. We collectively went too far. And this is just for broadband. Along came mobile. And as of early 2017, with mobile equal to or exceeding 50% of web usage, (depending on which report you read), we got us a little problem. A big one actually. And the thing is, “Responsive” design doesn’t really solve it. In fact, it’s maybe not even a great name. After all, responsive just changes the view for the Viewport size. It doesn’t do much about what’s coming down the pipe. (Or worse, over the air.) Adaptive templates for mobile can potentially solve some issues; just at what can be a large cost.
What shouldn’t be in question though, is there is a collective industry problem. Just in case you’re not convinced of that, please do check out one of the above presentations. Then consider making one of your upcoming Sprints a focus on Speed; from site architecture through frameworks, page internals and individual elements. Don’t forget the easy stuff that’s kind of a hassle, but worth doing: such as re-checking all graphics to make sure they really are optimized. And don’t give up on the hard stuff: such as tracing the dozens of third party code tags possibly coming down in your advertising areas to see if any of them are tripping you up.