Introductory frontend perfomance case on amazon.com
The first question you should ask yourself when thinking about Performance optimizations is the following:
Is my service unique enough to focus more on features and only do rudimentary performance optimizations, or do I rely on being the best in the business to attract costumers?
If you need to be the best because of generic features you should invest in the performance part, and here it is all about perceived performance.
The beginning of this talk captures the concept of perceived performance quite well.
A great metaphor taken from it:
Imagine going into a restaurant and after ordering you get everything at once. Your Drinks, Appetizers, Main Course and Dessert.
You would probably be wondering if anything will come at all and then be quite annoyed after waiting so long for everything.
With the resolve that you need to invest in performance you need to figure out what exactly can increase it for your project
To do this you have to analyse your users and what they need.
As always there is no silver bullet!
Dont blindly believe anyone who is trying to sell it you, if you are serious about it.
To help you start by answering these questions and come up with new ones yourself (feel free to share them):
- What is the main objective when loading the index page? Searching for sth? Getting some kind of information?
- Where are my users from? What devices are commonly used in that main areas of use?
- Am I building a web-app or a web site?
Lets say that you are
amazon.com and want to make your website fast.
The assumption that I will take here is that most purchases are made from mobile devices of all kinds.
Look at the slowest mobile device that is being used by real users (you can set a threshold here, of you like) and start optimizing for them.
For this example lets say that old Android phones are quite important. ( do not base your work on pure assumptions in real life, but back them up with data or by goals )
So lets get one of those and fire up
amazon.com to purchase something, all of this should be done with entwork conditions that resemble the ones of your users.
While doing this identify the most important parts of the site. Those should be immediately available.
In the following screenshot it should be clear that obviously the search is most important and probably the most common entrypoint into the website.
To start the purchasing flow this needs to be responsive as fast as possible and in the most barebones technology, meaning HTML.
Now that we figured out some things to improve we can come up with solutions to our problem.
Amazon has already done a pretty good job.
The inital HTML that is loaded is roughly 180kb big and the page looks like this:
Even if you do not load any more than this you will already be able to start doing something.
The code of the form looks like this
<div class="nav-searchbar-wrapper"> <form class="nav-searchbar" action="/gp/aw/s/ref=is_s" method="get" role="search" id="nav-search-form" accept-charset="utf-8" > <div class="nav-right"> <div class="nav-search-submit"> <input type="submit" class="nav-input" value="Go" aria-label="Go" /> <i class="nav-icon nav-sprite"></i> </div> </div> <div class="nav-fill"> <div class="nav-search-field"> <input type="text" class="nav-input" placeholder="Search" aria-label="Type search keywords" data-aria-clear-label="Clear search keywords" name="k" autocomplete="off" autocorrect="off" autocapitalize="off" dir="auto" value="" id="nav-search-keywords" autofocus/> </div> </div> </form>
Pure HTML that can be interacted with.
One thing to take away from this is that you want to provide actual functionality as fast as possible for the important paths in your website.
To do this you should have the initial HTML rendered on the server. Do not push everything into your client.
One funny thing is that amazon.com seems to detect if js is disabled, I gather this from the top of the document, saying:
<!doctype html><html class="a-no-js a-touch a-mobile" data-19ax5a9jf="mongoose">
Still, script tags are the first thing to come after that. These could be removed to make the initial load even faster. Although one might argue, that JS will be available on all relevant devices.
Please correct me if I am wrong on this one. My thought is, that the detection might be done by user-agent parsing.
The next files that get downloaded from the net are styling related.
Some interesting stuff happens here as well.
Depending on what device you are on you will get different kinds of logo sprites delivered to you in png.
This will make sense, if some of your supported devices do not support SVGs very well.
One improvement for faster devices could be loading SVG paths only. This would save them data, as they are able to render those.
This just scratches the surface of what you can do to improve performance for your website, and some might be way to costly to implement, where a new feature could give you
the edge over competition quickly.
Also this might not be as fun to do. Especially supporting older devices is and has always been a pain.
But if you do not cater what the user wants, you will loose out eventually. So always start by analysing that first. Your perspective will be tainted by being a tech-pro, but understanding the core
value that your business provides is VERY important.
This post might not provide any revelations to you, but I hope I can transmit to you the process of analyzing the problems first and then fixing them. Dont just copy/paste generic stuff from the internet.
The web is constantly evolving, but not all fancy features might be relevant to you, it might just be the simple ones that have worked for a long time.
If working in a fancy
react stack you might want to check out tools like after.js which will provide you with a good basis.