Quick and easy performance timing for your HTML5 page
When I was a teenager I had a job at Burger King. If you have never noticed it before, there is a large digital clock next to the drive through window, which tells the employee how long the customer has been waiting for their order. Measuring drive through wait time is a core KPI (of course, this was before I know what core-KPI meant) for these stores. In the end, what this really meant was that the drive through attendant would often just hit the “served” button as soon as the car drove up to window, instead of when the customer was actually served their order. To counter this, the stores started installing pressure pads underneath the drive through windows, to detect when the car actually drove away instead of relying on the teenager at the window. This is the real reason they will sometimes ask you to pull through and they will bring you your food, instead of making you wait at the window for a delayed order – it’s not for your convenience, they want to get you off that pressure pad.
My point here is the importance of counting the entire transaction when measuring performance. Web developers have a similar problem when measuring performance as the fast food drive through. Next time you hear someone talk about how quickly their page responded ask yourself, are they talking about the amount if time it took for the customer to actually be able to view and interact with the page, or are they referring to the amount of time it took for the HTML to be received by the browser (the “first byte” measurement).
Measuring the point that the HTML page was served up by the server is like a fast food chain only measuring the time it took to get the customer to the window. It’s a part of the story, but as far as the customer is concerned it’s not as important as the time it takes to complete the entire transaction and they can begin to chow down. According to Steve Souders, Google’s Head Performance Engineer, 80-to-90% of performance gains on a web page can be found on the front-end and not the back-end or network layer; yet many developers still ignore the time it takes the browser to actually process the HTML DOM and display the initial page.