Build resilient systems at scale
May 27–29, 2015 • Santa Clara, CA

Building the fast new MSN.com

Amiya Gupta (Microsoft)
4:10pm–4:50pm Friday, 05/29/2015
Location: Ballroom AB
Average rating: ***..
(3.57, 7 ratings)
Slides:   external link

Prerequisite Knowledge

Web performance concepts, knowledge of browser web development tools, and concepts of DOM, JavaScript, CSS.

Description

Optimizing for user-perceived performance is about so much more than minimizing round-trips and applying gzip compression. This talk will cover performance principles and optimization techniques applied to the recent MSN.com release, including:

  • Identifying the causes of and dealing with layout thrashing
  • Leveraging navigation and resource timings to measure perceived performance experienced by end users (and some obstacles encountered along the way)
  • Responsive design
  • Font loading and rendering: challenges and unexpected tricks
  • Enabling easy performance debugging on a variety of devices

Amiya Gupta

Microsoft

Amiya Gupta works on performance for MSN.com. His job involves investigating performance regressions, analyzing data, and data quality, educating other developers on how to create fast sites, and most importantly making MSN webpages load faster for users.

Comments on this page are now closed.

Comments

Amiya Gupta
06/23/2015 4:21am PDT

Hi Stephen
The slide isn’t meant to indicate all inline scripts execute 200x faster than external scripts. If it was that simple we would just inline everything. :)
In this particular case there was one small module (called “remToPixel”) that was part of the external JS. We saw that when it read the font size property that triggered a forced layout pass which is quite expensive on large pages like the MSN homepage. We tried several different approaches and the most reliable approach was to inline the module in the head. Even if it did trigger a forced layout (I don’t think it would invalidate layout on its own), there’s no layout to re-calculate that early in the page since the parser hasn’t gotten to the body yet.
Most of our JS is still loaded via an external JS reference to leverage caching. In this particular case the CPU benefits were so great that it made sense to inline those few lines of code.

Stephen Cunliffe
06/23/2015 3:49am PDT

Great presentation. On slide 35 the numbers seem to suggest that inline scripts in the head are better (200x perf wise) than in external scripts. Is this based on a “cold-start, un-primed cache”? I can understand if there was a latency issue fetching/resolving network resources but I’d like to believe that it is almost moot with cached external scripts. It would be nice to get some clarification.