Speed. It seems like that’s all I’ve been thinking about lately.
In the early days of the web, the Internet was slow. If you’re old enough to remember, the web moved through the phone lines. They were never designed to send much data. Just the electronic transmission of people’s voices. So it was slow. And we were just getting started. The web ran on phone lines, and its most stunning achievement up to that point was the invention of party lines.
If you know what a party line is, you’re a child of the 1980s, and I salute you.
We didn’t have much in the way of software back then to create webpages. We had the HTML spec and text editors. So we hand-wrote all our markup and made our pages as fast as possible. As browser technology grew and bandwidth speeds moved past phone lines, our pages became more complicated. The Great Browser Wars ran into that bandwidth barrier, though. We would create two versions of every site: one for Internet Explorer and one for Netscape Navigator. And our code was a mess because of it.
Around 1999, most designers and developers started to rally for web standards. That meant all HTML would become standardized, as well as how it loaded in every browser. It worked, slowly at first, and then all at once. Browsers started to adopt to web standards. Finally, we were done making workarounds and duplicate sites.
Afterward, bandwidth exploded. Web 2.0 began, and we started to make our websites act like desktop software. We started to develop complicated templates and libraries to speed up development. We stopped creating our code by hand. Everything was developed on frameworks with existing content management systems. Sites with large codebases became the norm. We came to a point where “web designer” was an outdated term. The job splintered into different specialties to support all these frameworks.
And then mobile devices came on the scene, and we’re back to speed being an issue again.
There are workarounds to the mobile problem that seem wrong. Especially in the spirit of the web standard movement. You can create a separate mobile site. Or you can serve different, responsive designs based on screen size. It’s a mobile-first world, and once again, I’m starting to see the need for speed. Instead of having giant Javascript libraries load in all at once, we’re trying to load them last. Database caching. Preloads. Search engines penalize your sites if they aren’t fast.
Which is why I find the rise of flat-file content management systems fascinating. Unlike WordPress, which uses a database, a flat-file CMS uses text files to create static HTML files. Instead of your website making several calls to a database, it would load clean and fast. And it’s all run on plain-text files. That’s it. The most simple of files to understand. All you need to work on your site then would be a text editor. And I feel like I’m back to 1995 opening up Notepad to write my first line of HTML.
Mobile speeds will improve. That’s a given. It’s just not in carriers’ best interests to make their networks slower. And when that happens, I expect we’ll go on a mad run of pushing the mobile web to its limits, just like we did on the desktop. But I, for one, like how speed necessitates simple. Sometimes, the best, most eloquent solutions are the ones that are the simplest.
This was originally published on the B² Interactive blog.
