By Tim Kadlec CHAPTER 4from the HTTP Archive^1. We’re heading the wrong way fast. Usually, we
don’t even notice it as it happens — and if we do, it’s often too late.
I was talking to a developer about a new website that he had been
working on. The website was certainly well crafted. It was a little on the
heavy side though. Not much, but enough that he felt the need to explain
the situation a bit. What he said highlighted the issue with Web perfor-
mance in general. “I doubt anyone really wants to release a site that doesn’t
perform well,” he explained. “It’s just a product of not being afforded the
luxury of time and top-down pressure.”
Feel like you’ve been there before? Most of us, I’m sure, can easily relate
to this. I know I can.
I was working on a project where I was collaborating with a team of
internal developers. From the very beginning, everyone stated that, among
other things, they wanted the site to be very fast. The developers I was
working with were very good at their jobs, and given the seemingly high
level of importance being placed on performance there was good reason to
believe this was going to go well. But then it didn’t.
Early mock-ups were shown to upper management before being shown
to developers. By the time the developers saw the mock-ups, they had
already been approved by the powers that be. There was no opportunity to
try to alter them based on any potential performance risks (and there were
several).
Then an internal deadline was set based on business requirements that
significantly altered the aggressiveness of the timeline. The combination
of tight timescales and ambitious mock-ups approved too early led to yet
another issue. “Make it fast” quickly turned into “Make it work. We can
always make it faster later.” Of course, later never came.
And so, after a lot of very hard work, we were closing in on launch and
the performance of the site was a disaster. It was slow, sluggish — every-
thing none of us wanted it to be.