Performance Optimisation, my first talk ever


Performance Optimisation from Fabio Cicerchia

At the end of 2016, I gave a talk at the PUG Roma meetup talking about web performance. Despite my expectations of a first-time shy speaker, the room was packed with more than 50 attendees.

Here it is the script of the talk.

  1. Performance is a process, not a project Every engineer should think about performance
  2. Time is Money Unfortunately you can’t buy it, so don’t waste it
  3. Performance matters



  1. Accurately measure page performance
  2. Be unobtrusive
  3. Have a good sampling
  4. Focus on useful metrics

Random Sampling

Strip from XKCD about how to generate a number in a funny way How to randomise?

  • Pick 10% of users at random and always test them
  • For each user, decide at random if they should be tested


Central Tendency

  • Mean(10, 11, 12, 11, 109) = 30 Affected by outliers
  • Median(10, 11, 12, 11, 109) = 11 Central tendency
  • Mode(10, 11, 12, 11, 109) = 11 Most recurring value, not often used


  • Percentiles are perfect for automatic baselining.
  • Averages can be misleading.

Keep an eye on:

  • 50th percentile = Median
  • 95th percentile
  • 98th percentile
  • 99th percentile
  • You can’t improve what you can’t measure




The Time To First Byte metric is affected by 3 components:

  • The time the request takes to reach the web server
  • The time the web server takes to process the request and generate the response
  • The time the response takes to go back to your browser



As per TTFB the reasons for a high Time To Last Byte could be:

  • Geographic latency (server is far away from visitor)
  • Poorly written server-side code
  • Outdated server hardware
  • Overloaded servers (clogged bandwidth due to high traffic – from humans, bots, or both)
  • Poorly organized databases
  • Poorly written database code

DOM Content Loaded

  • It’s fired when the HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading. A very different event load should be used only to detect a fully-loaded page. It is an incredibly popular mistake to use load where DOMContentLoaded would be much more appropriate, so be cautious.


Full Load

// 1
document.addEventListener('DOMContentLoaded', function (event) {
console.log('DOM fully loaded and parsed');

// 2
function load() {
console.log('load event detected!');
window.onload = load;

// 3
$(document).ready(function () {

// 4
$(window).load(function () {

1. ready
2. DOM fully loaded and parsed
3. load event detected!
4. loaded

Speed Index

Example of Speed Index loading progress

  • The Speed Index is the average time at which visible parts of the page are displayed. It is expressed in milliseconds and dependent on the size of the view port. The Speed Index metric measures how quickly the page contents are visually populated (where lower numbers are better).


Some Figures

3rd Party?

  • 3rd party calls can make up >50% of page requests.
  • They are the single greatest potential point of failure for web pages.



  • GZIP compression saves 50% to 80% bandwidth and it will significantly increase the website’s loading speed.
  • Netflix saw a 43% drop in outbound traffic after enabling compression





  • 20% pages contain 5 or more redirects.
  • And 3% of pages contained 10 or more.


100ms slower?

  • 1% drop in sales (Amazon)


500ms slower?

  • 25% drop in searches (Google)


1 second slower?

  • 11% fewer page views, a 16% decrease in customer satisfaction, and 7% loss in conversions


2 seconds slower?

  • During a transaction results in abandonment rates of up to 87%. This is significantly higher than the average abandonment rate of 70%.


3 seconds slower?


4 seconds?

  • Only 2% of the top 100 e-commerce sites loads in fewer than 4 seconds on smartphones.


10 seconds?

  • 1 out of 4 pages took more than 10 seconds to load.
  • 20% of the top 100 e-commerce sites loads in more than 10 seconds.


To infinity… and beyond!

  • According to Google’s DoubleClick, when comparing sites that load in 5 seconds to sites that load in 19 seconds, the faster sites had 70% longer average session lengths, 35% lower bounce rates and 25% higher ad viewability than their slower counterparts.
  • Google’s DoubleClick found that publishers whose mobile sites load in 5 seconds earn up to 2x more mobile ad revenue than sites loading in 19 seconds.


Poor Performances = Web Stress

  • Brain wave analysis from the experiment revealed that participants had to concentrate up to 50% more when using badly performing websites, while facial muscle and behavioural analysis of the subjects also revealed greater agitation and stress in these periods.


Long story short…

  • You are LOSING Visitors
  • You are LOSING Sales
  • You are LOSING Ad-revenue
  • You are WASTING SEO/SEM/PPC budget
  • SPENDING $$$ on bandwidth and servers

So, how to do it?

Let’s do it!

Level 0 – Noob


  • You send zipped content over the wire, the browser unpacks it
  • Modern browsers understand compressed content
  • Search engine spiders do too


  • Minify JavaScript and CSS
  • Inline styles and scripts should also be minified
  • The Source Maps are loaded only in Dev Mode

Avoid 404s

  • Useless requests
  • When an external JavaScript is a 404, the browser will still try to parse it and find something usable in it
  • They’ll slow down the UX

Optimise Images

  • Lossless optimisation
  • Correct dimensions
  • Save for web
  • Use the right file format: GIF for animations, JPEG for photograph, otherwise PNG
  • Don’t Scale Images in HTML


Optimise CSS Sprites

  • Choose horizontal over vertical when possible
  • Combine similar colors
  • Keep color count low
  • Don’t leave big gaps

Back to basics

  • Google’s Rules
    • Avoid bad requests
    • Avoid CSS expressions
    • Combine external CSS
    • Combine external JavaScript
    • Defer loading of JavaScript
    • Enable compression
    • Leverage browser caching
    • Leverage proxy caching
    • Minify CSS
    • Minify HTML
    • Minify JavaScript
  • Yahoo’s Rules
    • Minimize HTTP Requests
    • Use a Content Delivery Network
    • Add an Expires or a Cache-Control Header
    • Gzip Components
    • Put StyleSheets at the Top
    • Put Scripts at the Bottom
    • Avoid CSS Expressions
    • Make JavaScript and CSS External
    • Reduce DNS Lookups
    • Minify JavaScript and CSS
    • Avoid Redirects

Level 1 – Getting Serious


  • The browser will request it
  • Better not respond with a 404
  • Cookies are sent
  • Cannot be on CDN
  • Interferes with the download sequence
  • Make it small (<= 1K)
  • Animated favicons are not cool
  • Set Expires header

Minimise iframes

  • Pros:
    • Can help with slow third-party content like badges and ads
    • Security sandbox
    • You can download scripts in parallel
  • Cons:
    • They have a cost even if blank
    • They block page onload
    • Non-semantic

Post-load Components

  • What’s absolutely required in order to render the page initially?
  • The rest can wait (drag and drop, animations, hidden content, images below the fold)

Preload Components

  • Items you’ll need in the future
  • Unconditional preload ( loads a sprite onload)
  • Conditional preload ( after you type in the input box)
  • Anticipated preload – preload in advance before launching a redesign
  • When you start typing the page can safely assume you’ll hit the search results page

Use Cookie-Free Domains

  • Option 1: Separate subdomain (
  • Option 2: A new domain (e.g.,,


  • ETag is a token that can be associated with a web resource
  • ETags are meant to help with caching
    • They take precedence for caching
    • They never expire
  • Issues with load balanced environment
    • A component served from server A has a different ETag than the same component served from B
  • Most of the time you don’t need them


Reduce Cookies

  • Eliminate unnecessary cookies
  • Keep cookie sizes as low as possible to minimize the impact on the user response time
  • Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected
  • Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time

Event Handlers

  • Don’t wait for onload, use DOMContentLoaded
  • Events bubble up, so use delegation (attach listeners to outer elements)
  • Clean up to prevent IE memory leaks
  • Careful with onresize

Choose <link> over @import

  • CSS should be at the top
  • @import blocks parallel downloads
  • In IE @import is the same as <link> putting at the bottom
  • <link> allows alternate styles (e.g. for accessibility)


Level 2 – Advanced

Reduce DOM Elements

  • World’s fastest page? about:blank!
  • A complex page means more bytes to download, it also means slower DOM access in JavaScript
  • Easy to test, just type in Firebug’s console: document.getElementsByTagName(‘*’).length


  • DNS prefetching → resolve the DNS
  • Preconnect → resolve the DNS + TCP handshake + TLS negotiation (optional)
  • Prefetch → requesting, downloading and storing the asset in the cache
  • Prerender → load all of the assets of a certain document



  • The most important and interesting section should be at the top of the webpage
  • Make sure to render the Above The Fold content in < 1s
  • Defer the non-AFT contents


Requests Sharding

  • Domain sharding is a technique for splitting resources across multiple domains, improving page load time. When multiple domains are used, browsers are able to download more resources simultaneously, resulting in a faster user experience. Note: HTTP/2 has officially replaced SPDY and made it obsolete.



Speed comparison of some methods using different frameworks References:

Avoid Filters

  • Blocks rendering, freezes the browser Increased memory consumption Per element, not per image

Web Fonts

  • Blocks text rendering
  • Fonts are bigger than 14Kb
  • Use them with care
  • Remove characters


  • WebP is a modern image format that provides superior lossless and lossy compression for images on the web.
  • WebP lossless images are 26% smaller than PNGs and 25-34% smaller than JPEG images.



  • Don’t animate from JavaScript for basic stuff
  • Use requestAnimationFrame
  • Have a look at GSAP (20x faster than jQuery) and VelocityJS


HTML5 Features

  • Application Cache Service Workers
  • Web Storage
  • Web Workers
  • Navigation Timing API
  • Web Sockets



Example of rendering of a web page

  • Optimizing the Critical Rendering Path refers to prioritising the display of content that relates to the current user action.
  • Perceived Performance is a measure of how quick a user thinks your site is


Level 3 – Behind the Scenes


  • Latency is the amount of time it takes to transmit a single piece of data from one location to another
  1. Decrease External HTTP Requests
  2. DNS Prefetching
  3. Preconnect
  4. Use a CDN
  5. HTTP/2
  6. Caching



CDN explaination Get a Content Delivery Network:

  • Akamai
  • CDNify (from $10/m)
  • CloudFlare (free-mium)
  • MaxCDN (from $9/m)



  • What is dynamic content? Almost everything is static for a time. The hard part is to reduce the miss rate.
  • What can you cache?
    • DB Results
    • Functions Output
    • Generated HTML
  • There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton



  • SPDY is now deprecated
  • Allows concurrent HTTP requests in one TCP session.
  • Reduces the bandwidth used by HTTP (header compression & cleaning useless headers).
  • Makes SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure.



  • Origins from SPDY by Google
  • HTTP/2 is protocol designed for
    • Low latency transport of content over the Web
  • No change to HTTP semantics
    • It’s about how data travels through the wire
  • Key new features in HTTP/2
    • Multiplexing: multiple streams over a single connection
    • Header compression: reuse headers from previous requests
    • Server push: multiple parallel responses for a single request
    • Prioritisation: some resources have priorities
  • HTTP/1 workarounds hurt HTTP/2 perf.
  • Antipatterns
    • Domain Sharding
    • Images Sprites
    • Resource In-Lining
    • Merging CSS & JS



  • HTTPS requires an initial handshake despite it’s size (~5KB) it can be very slow.
  • Making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.
  • Solution: Improve the Handshake + Keep-Alive.


Level 4 – Backend Superstar


Example of XHProf profiling Example of Flame Graph

SF Profiler

Example of Symfony Profiler graph

Level 5 – Mobile Ninja

  • Summary
  • Slow Network → Reduce Reqs + Reduce Bytes
  • Weak CPU = Slow JS → Async + Defer
  • Focus on ATF
  • Different Connection Model → Reduce domain sharding, Reduce 304s
  • Cache → localStorage


Level 6 – Guru


  • PRPL is a pattern for structuring and serving Progressive Web Apps, with an emphasis on the performance of app delivery and launch. It stands for:
  • Push, critical resources for the initial URL route.
  • Render, initial route.
  • Pre-cache, remaining routes.
  • Lazy-load, and create remaining routes on demand.



Snippet of AMP code


  • Edge Side Includes is a language specification for assembling fragments of web pages inside other web pages.
  • Example:<esi:include src="" alt="" onerror="continue"/>


Reverse Proxy

Network graph of a Proxy and of a Reverse Proxy

  • A Reverse Proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated from the proxy server itself.
  • Common choices:
    • Varnish
    • Squid
    • HAProxy
    • Nginx





Chrome Developer Toolbar Safari Developer Toobar Firefox Developer Toobar

Understand the Waterfall

Example of Resource Loading in Waterfall Graph References:



You Don't Know JS Performance High Performance MySQL Optimization High Performance Mobile Web High Performance Web Sites Essential Even Faster Web Sites Performance Designing Performance Weighing Aesthetic Speed Web Performance Tuning Speeding Performance JavaScript Faster Application Interfaces

Are you lazy?

Which ones are the most important/common?

Strip from XKCD about how premature optimisation is the root of all evil These 5 ones:

  • Reduce Page Size (<500Kb)
  • Enable (GZip) Compression
  • Reduce the number of round trips (<40 per page)
  • HTTP Cache Headers (cache long & prosper)
  • Structure the page (to improve render & download)
    • CSS First
    • Javascript last
  • Even if you apply just those 5 rules…
  • Your page download times will drop by ~50%
  • Premature optimization is the root of all evil — Donald Knuth


Bonus #1


Bonus #2


Bonus #3