Training: June 20–21, 2016
Tutorials: June 21, 2016
Keynotes & Sessions: June 22–23, 2016
Santa Clara, CA

Scaling frontend performance

Patrick Meenan (Facebook)
1:15pm–1:55pm Thursday, 06/23/2016
Performance for the people
Location: Ballroom CD Level: Intermediate
Average rating: ****.
(4.92, 12 ratings)

Prerequisite knowledge

Attendees should have general experience with website development (JS, CSS, HTML) and a basic understanding of how HTTP works over TCP.


The range of connectivity for visitors has never been wider, encompassing every possible combination of latency and bandwidth (gigabit fiber, satellite, cable/DSL, dial-up, LTE, 3G, 2G, etc.), and usage is growing at both extremes. Serving a fast experience to visitors on slower connections does not mean having to sacrifice a rich user experience or serving different versions of content.

Patrick Meenan outlines techniques for measuring the current user experience and dynamically adjusting the content to consistently deliver a fast experience—including dynamically adjusting image quality (without a custom image server), effective lazy image loading, optionally including third-party content, and static content serving/CDN planning—dives into issues specific to slower mobile connections where how you construct and serve your content can reduce an already slow connection to one where almost no content can successfully be delivered, and explains how HTTP/2 and proxy browsers can help.

Photo of Patrick Meenan

Patrick Meenan


Patrick Meenan is a software engineer at Facebook, where he’s helping make the web faster. Patrick has been working on web performance in one form or another for the last 25 years. Previously, he worked at Cloudflare and Google to make Chrome and the web faster. Patrick created the popular open source WebPageTest web performance measurement tool, runs the free instance of it at, and can frequently be found in the forums helping site owners understand and improve their website performance.

Comments on this page are now closed.


Picture of Patrick Meenan
06/28/2016 9:27am PDT

Sorry, the better estimate for RTT from the client side is actually connectEnd – connectStart.

responseStart – navigationStart is equivalent to what WPT reports as TTFB which is everything that went into the time for the HTML to actually get to the browser and is just a better time for “how long the user has been waiting”.

Picture of Pierre Lermant
06/28/2016 8:22am PDT

Pat, regarding the Client-Side Decisions, the most important parameter is the RTT between the client and the server handling the connection (origin server or CDN edge server). You indicate in slide #19 that the delta (performance.timing.responseStart – performance.timing.navigationStart) should give the TTFB, a good proxy for RTT. From the Navigation Timing spec, it looks like the delta (performance.timing.responseStart – performance.timing.requestStart) would also give a measure of TTFB. These 2 measures of TTFB are probably pretty close however I wanted to ask you why you picked navigationStart over requestStart.

Picture of Patrick Meenan
06/25/2016 12:40am PDT

Sorry about the delay. Slides are up now:

I’ll post the video as well in a few weeks when it becomes available.

Picture of Pierre Lermant
06/24/2016 3:01am PDT

Hey Pat, would you have an ETA for making your slide deck available. As always, was a great presentation that made me think …