These past 10 years have hosted a huge evolution in our data distribution technology. Since 2000, we’ve watched household broadband speeds move from about 0.5 mbps to somewhere around 20 mbps on average. This is awesome.
We have new LTE networks that are capable of pushing around 50 mbps over the air. Please note: this is faster than most household connections.
We live in an era of increasing bandwidth, and this is good news for web developers. This allowed sites like YouTube to become popular, because they finally had customers that could enjoy their product.
But developers have new struggles! Now, developing truly mobile applications (both native apps and web apps) must account for the new obstacle: carrier data caps.
How annoying. We’ve finally been given a trove of bandwidth (both low latency and high capacity), and we have to start using it very carefully–dare I say responsibly…
It’s food for thought. We have better networks and more ubiquitous access but increasingly more consumers have charted courses for the edge of a bandwidth cliff every single month.
So we must continue to adapt.
Things That Are Concerning
- Popular development frameworks can be rather bloated. Twitter Bootstrap (minified) is 101kb and another 17kb if you want the responsive tweaks. .
- Responsive images are not really taking off. Even Apple does not have a decent implementation for responsive image serving that doesn’t involve convoluted Javascript.
- Developers that don’t pay attention to client-side caching techniques. Make browsers get changes by using ?ver=[autoincrement] to force browsers to reload only when content changes.
- Everybody wants “apps” and these apps need data. Lots of these apps send a lot of data (either as JSON or XML) without implementing a cache mechanism. Twitter uses a neat trick to keep data transfer down: the since_id query parameter. This minimizes payload by ignoring content that the client probably already has.
- XML has too much data overhead on structure to be considered efficient, yet it is hailed as a great data interchange format–NOT FOR THE WEB! Typically ever XML tag is matched by a closing version of the tag. Look at the overhead here: <strong>this is bold text</strong>. The strong tag and its closing tag take up 17 characters, which is equal to the length of the content it formats. This is a massive overhead! Mobile clients shouldn’t rely on XML for updating content (like a timeline of continuously updating information).
This was merely a brief rant about implications about data load. This doesn’t even consider some of the changes that occur with data throttling, and packet shaping.
Worrying about data overhead is the new black.