Balancing design and resource availability
Performance-based budgeting establishes a relationship between program expectations and expected results from that program. It's meant to establish a balance between how awesome you can make something look and how much overhead it will take to actually serve that something up.
Performance budgets can also help administrators, designers and developers understand how a digital product will stack up against its competition.
It depends. Maybe. Probably.
Depending on what your website or application does or which devices you are targeting, a performance budget may be essential to your process. If it puts your organization in a less reactive state and in a more predictive space, it's probably a good thing to do.
Let's compare the sites of two pretty large companies.
I don't work for either of these companies. I don't have any insight into why they have made any of their design or development decisions.
I'm not saying any company is doing a better or worse job than the other. But, that doesn't mean it's not an interesting comparison!
Let's compare Comedy Central's site with HBO's. Both are large, complex operations that are serving tons of data and targeting multiple devices and browsers.
I'm using an online utility that measures website performance to simulate how the two sites perform on a 1.6Mbps Mobile 3G connection. I'm running 3 tests on each site without any caching and using the average test for this comparison.
Some very basic content has been painted.
Just a white screen, so far.
Ah, some more content.
Still a white screen...
Look at all that great content I have!
There's all my content! I can't wait to look at it all!
It's not really that easy.
Comedy Central's site actually loads for another 14.5 seconds.
However, a user not only gets control of the Comedy Central site much earlier than HBO's, they can see content and navigate it.
On the other hand, HBO's site is 100% ready when it is loaded.
There is a strong argument for giving your users control as soon as possible, even if all of the content isn't loaded. It's possible that a user could discover a menu item or button they need to press long before the page finishes loading.
In that case, all of that great content on the homepage may not need to load because the user doesn't need it.
Several factors conspire to produce bottlenecks, block page loading, hamper content delivery and prevent a user from interacting with the DOM.
Take a look at HBO's content breakdown:
Comedy Central has a completely different content breakdown:
Comedy Central has a "base.css" stylesheet that loads basic page elements quickly. Later, a larger stylesheet fills in the rest of the page styles.
Meanwhile, HBO has one, quite large, CSS file that appears to be targeting almost every device screen size one can think of.
HTML, CSS and Javascript files are in the critical rendering path for web pages. So, sadly, first screen paint is blocked until that large CSS file is brought in from the server or CDN.
As designers, we want to make things that are pleasant to look at. However, we are shoving these things across data servers and cloud containers to myriad devices in myriad locations.
I'm not advocating the sacrifice of aesthetics over performance! I am, however, advocating using this type of tool to pinpoint exactly where your performance hits exist.
When was the last time you waited over 3 seconds for something to load and didn't think something was wrong?