Fewer Requests vs. Response Sizes

It is well known that when it comes to requests it's best to have fewer on a page for better performance.  However, what if our attempt to do this creates very large responses?  In this situation is it still a good idea to maintain this rule or should we split a request into multiple asynchronous parallel requests that return smaller responses?  That was the question that came up the other day as I was testing a site and noticed that one of our javascript libraries was starting to creep up in size even though it was minimized and gzipped.  In order to answer this we need to keep in mind several other rules that deal with receiving the smallest response we can.  In situations like this, where performance rules can collide, which ones should we give priority to?  Should we ever break the rule of fewer requests?  To answer this, let's dive into the rules...  

Webpage performance - Key Indicators

There is a lot of talk about what you should be looking at to determine if your page is performing optimally.  With today's front end architecture's it is generally accepted that several indicators are no longer valid - i.e. domComplete and onLoad.  We also know that reviewing the full page time is not a true indicator given that most critical functionality for page interaction may be loaded well before your page is fully loaded.  With all this in mind what are the most critical indicators that we should be looking at?

First lets clarify that in this article I'm only speaking about the page's initial load/render performance.  While I believe that each indicator has it's own place in the world of performance there are a few key indicators that we use at StubHub to track our page's performance.  We have 2 main indicators that we track against company KPI goals.  The first is time to interact (TTI) and the second is Full Page Time (FPT).  I know what your thinking, "But wait, you just said that Full Page Time is not a good indicator of performance.", while this is generally true, the FPT indicator is a good reference for keeping 3rd party and non-critical functionality in check.  Other indicators, non-company KPI goals, that we use deal with time to first byte (TTFB) and the loading of ads.

You might be asking "why don't you look at several of the other indicators, given that you've stated that each indicator is important?".  The reality is that we do utilize many of the other factors - page weight, requests count, etc...; however we utilize these as to help us set our KPI goals and to help us tune our pages.  I've found it especially useful to use these other indicators when giving the design teams a rough set of guidelines around page design and performance impact, which I might discuss in another article.

Putting your website on a diet

BEFORE

AFTER 

Most websites are just like me after the holiday's have past and I realize that I ate too much turkey, stuffing and pie; they are prone to events that cause them to incur page bloat.  However, just like me at the end of the holidays, we can put our website on a quick diet and then recommit ourselves to that regularly maintained healthy lifestyle.