Every Perfect Housewife sometimes has to iron freshly washed and dried clothes. It’s a common task for every week of the year. She has to iron everything but there are some simple ways to get ironed only parts of the laundry. The secret is stretching clothes before drying.
We are living in a time when broadband Internet is easily accessible but not every user of website or webapp has access to it. So as a front-end developers we have to deal with responsiveness of the user interface. The key problem for a user experience of a website is time between when user requests a site and when he gets some content from it. Thinking about that we need to make a page load time below 1.5s. This is a real boundary: if the page loads longer the user is more frustrated and probably will choose another service or website. So, go fight with lags, latency, unreachable assets and more.
- minimal size in bytes of associated assets (images, CSS, JS)
- minimal number of http requests made by browser to download assets
- effective use of CDN (Content Delivery Network)
- inline styles for rendering the part of a page visible in viewport
- attaching external CSS at the head part of a document
- attaching external JS files at the end of a document just before
- asynchronous load of assets i.e. using lazy load for images
- use of effective css selectors
You can always test the site against page rendering time using your browser’s Developer Tools or for example Web Page Test or similar services.
With optimizations mentioned above there is also one thing to remember: the HTTP Headers.
As a developer you have to plan and maintain optimal use of browser / proxy cache. The only way to do that is a proper configuration of your webserver. There is no special difference between setting up this on IIS, Apache, nginx or any another server. You have to remember to set HTTP headers within documents served by your application. Probably you are familiar with HTTP headers but I don’t think so. Example set of response headers with cache control:
HTTP Headers can make your content cached by the browser for a specific time - the longer the better. For the time you specified within headers the browser will not even asks server for an asset.
- test page initial load time with empty browser cache then optimize page rendering time
- test page load time with filled cache
Last months brought some change to HTTP world, the HTTP/2 Protocol (similar to SPDY) which deals better with a lot of consecutive requests to the same server, making some kind of tunnel and getting assets at once. There are available modules for Apache and nginx but there is no implementation for IIS right now. The cons of HTTP/2 is a mandatory use of SSL which may be a performance penalty.
Pros and Cons
- happy users :)
- savings on data transfer costs
- beautifully configured webserver
- lot of knowledge you probably didn’t have now
- +10 to exp ;)
- costs time
Things to read, things to use
Remember: Stretch clothes before drying. RTFM :)