Fast Might Not Be Better2016-01-14
I've recently been simultaneously amused and horrified reading about
website obesity, and the
"Fastest Blog in the World"
and decided it was time for a periodic reassessment of this site's
I prefer a minimal (to the point of being spartan) approach to web design which,
while not always in style, affords me fast page loads. For most of the pages
you'll find on this blog there are only two network requests1: the first for
HTML and the second for the
CSS. In an effort to reduce "bloat" I did my
best to simplify the stylesheets down to just 19 rules in as many lines. I'm
cheating a bit with a single line per rule, but it's a very small hack inspired
by another blog. I'm not entirely sold on
the idea but with so little styling I think it does not detract from my ability
to understand or modify it if need be.
At What Cost?
It is a curious balancing act to weigh the relative benefits of developing things quickly and "doing them right"; especially when "right" is such a subjective idea. Where do you draw the line in using a sort of prefab setup and tilting at windmills while reinventing everything yourself?
Having made such a minor change to this site got me thinking about the trend of bloated sites. I don't disagree with the assertion that "We don't have to care. The network is fast." for plenty of cases, but I can't help but think that there is more to it than that. It seems as though plenty of folks are trading speed of development for actual page speed; short-circuiting fundamental design decisions by deferring to a framework or mimicking another project.
Elements of Design
I've been reading the Design Basics Index, which is not intended as a web design reference, but rather a general guidebook for thinking about design. Taken literally, lots of the examples look dated and of questionable value, but the message is not bad. A fundemental aspect of design is knowing how something will be used. I think lots of sites miss this point, over-valuing developer time to the detriment of the project as a whole.
By removing many of the fundamental decisions in a site's design I think we lose sight of how it is intended to be used. It is no doubt faster and easier to just drop in a framework, but it often misses the mark. By dropping Bootstrap or Pure or Foundation into a project, developers get drop-in grid layouts and navbars and buttons, but because they don't have to write it they don't seem to spend any time deciding whether it's a good idea in the first place.
It's a separate issue entirely whether the tech community is advocating these sorts of practices with the near constant talk of "tech stacks" and whatever new hotness was released today; but I get a definite sense that the web could be radically simpler if people were forced to write more of it themselves. I don't think there should be less options for open source libraries and frameworks but I do think there should be more careful consideration for their use.
So What Am I Going To Do About It?
For now, I'm not sure what I can do. I'll continue to chase page-load benchmarks and write it all by hand. While I think there's real value in semantic HTML and minimal "cruft" on top of it all, I can only do so much. I think the only thing for me to do is try and ride this one out. It might not be leading by example, but it can't hurt.
- I should eventually get around to optimizing these two requests with
HTTP2, but that's dependent on
SSL/TLSand there's only so many hours in the day.