It was 1995 when I discovered the internet at the Utrecht University. I studied quantitative analysis for sociology, which meant generating pages of statistical data to support the empirical analysis of some hypothesis in my report. There was one matrix printer that dozens of students had to share, so it could take a while. As I waited, I surfed the web (dds.nl) in Netscape and quickly learned that slow internet is worse than no internet.
More than 20 years later, I have a mobile phone with more computing power than all those computers in the university thrown together. It has a selection of browsers, each of which eats more RAM than the size of a then-large local harddrive. You could say devices and browsers have scaled up significantly over the past 20 years. And yet, when I'm on my way to work, more often than not I find myself struggling to get a good 4G or even 3G connection. More often than not, I'm finding that slow internet is still worse than no internet.
Any decent web developer these days should be able to explain the necessity of progressive enhancement. At its core, it's about making sure the common denominator of browsers is as big as possible when designing core functionality for the web, adding additional less vital features depending on device & browser capability.
My colleague Sybren Wartna wrote an article about progressive enhancement and its relation to slow internet in this day and age: http://blog.mirabeau.nl/nl/articles/wanneer_progressive_enhancement_in_het_echt_nodig_is/4iNM6bjJOgGwk2CYo02m2U
The story doesn't end here.
Post-delivery code as content
- This is where many websites abandon decorum and do all that the cautious frontend developer worked hard to avoid.
- This is where the websites are spawned that load in 2 seconds and then spend another 6 waiting for various scripts to load and execute.
- These are the sites where flash of unstyled content (FOUC) transgressions are so foul you suspect intent when you click an ad where a link was, because the content was still jumping around 3 seconds after it first appeared in your browser.
The browser doesn't scale
Everyone's going to the cloud, be it public, private or hybrid. The premise is: Your servers scale to your needs with so little hassle, that as long as you make sure your online strategy works, any cost for a bigger server park is compensated by an increase in conversion.
Now here's the thing: your servers scale. Your visitors' browsers do not. What I mean to say is this: Anything you want to show your visitor, you should try to generate on your server on the first load, where you have the capacity to scale.
I'm also saying: reconsider your tracking scripts. Do you really need 8? Do you realize you may be missing behaviour because your tracking script hadn't finished loading before your visitor clicked on a link?
Browsers do not scale. Servers do.
If all this means that you need a faster backend, then scale up – that's what the cloud is for! Odds are that a potential customer will sooner leave your site for a competitor's than buy a new device or wait until he's home on his trusted cable internet desktop PC to visit your site.