Building The Fast New MSN

Building the Fast New MSN.
com
AMIYA GUPTA
@amiyagupta
May 29, 2015
Brand new UI
New MSN
Other cool stuff that I wont
have time to talk about
Entire stack on Azure PaaS

New geo-distributed Content Store
Responsive design
Single Web codebase for all verticals
Perceived Performance
Browser Jenga
Achieving and maintaining fast
rendering performance can be
like playing Jenga
Basic
Intermediate
Advanced
Gzip compression
Basic Practices
Baked In
Configured in a single place in
the core SDK; transparent to
developers
Cookie-less domains
Far future caching headers
CSS and JS bundling
Minification
Domain sharding
Image spriting
Image compression
Basic
Intermediate
Advanced
Async Script
Attribute
The async attribute allows
scripts to load in a non-blocking
fashion.
DNS Prefetch
Links in the <head> hint the
browser to perform DNS
lookups for domains that will be
referenced further down the
page.
DNS lookups
Homepage
Single jQuery URL

Leverage the benefits of
browser caching; avoid multiple
instances of a framework on the
same page
Article
Gallery
Video
Above Fold
Lazy-Loading
Images Below
the Fold
Images in the viewport are
fetched immediately, rest are
lazy-loaded
Below Fold
Above Fold Content: 250KB
Size Budget
250KB for Above-Fold Content:
HTML
CSS
JS
Images
WOFF
Basic
Intermediate
Advanced
Quantifying
Perceived
Performance
Perceived Performance is
usually measured using
filmstrips of the page rendering
sequence
Visual Metrics
Algorithms like Speed Index and
Page Phase Time attempt to
quantify perceived performance
based on the rate of change of
pixels on the screen. The
resulting metric is usually a
single number.
Our Approach to
Visual Metrics
General purpose metrics are
great, but they can be a little
opaque when it comes to
identifying the cause of a
regression. Our approach
focuses on time taken to render
specific sections of the page.
First Render
Hero Image Render

Above Fold Render
Ad Render
What We Learned
Network isnt always the bottleneck
Looking at the waterfall isnt enough
CPU cycles spent on

repeated layout/styling operations
Forced Layout Operations:

The Silent Killer
Understand
Identify
Fix
Rendering Pipeline
The browser usually cycles
through this process several
times during initial page load.
Sequence of two actions necessary for a

forced layout operation:
Killer Combination
1. Modify: Invalidating a section of the

display tree through DOM or style
updates
2. Readback: Reading a property under
that tree when invalidated: e.g.
clientWidth, getBoundingClientRect
Impact
Small, seemingly harmless DOM

operations can trigger expensive
operations and result in repeated work
CPU time spent in this extra work slows
down overall rendering
Thats why
Understand
Identify
Fix
F12 Tools
Browser profiling tools are the
best theyve ever been
Perf Markers
Flame charts can be
overwhelming to look at.
Adding performance markers to
critical sections of your code
makes the visualization easier to
understand.
Drilling in with
Perf Markers
What to look for

Repeated expensive
Layout/Style operations are
killing your rendering
performance
Understand
Identify
Fix
Wherever suitable:
Solutions
Batch writes together

Avoid client-side inserts if they can be included
server-side
Execute reads before writes
Schedule read and write operations with
requestAnimationFrame
Move operations into the head or outside the
DOM
Example:
Modernizr
Putting Modernizr in the wrong
place resulted in three
consecutive >100ms style
recalculation operations when it
ran its feature detection tests.
350ms
Example:
remToPixel
200x speedup by moving from
external JS to inline head script
Script Location
Execution Time
Before
External JS
86.2ms
After
Inline in <head>
0.5ms
The Future
HTTP/2
Moving to HTTP/2 means we
will have to un-learn some
common best practices
Cookie-less domains
CSS and JS bundling
Domain sharding
Image spriting
In Conclusion
Basic: Bake in common best practices
Recap
Intermediate: Incorporate relevant newer

performance features
Advanced: Attack the silent killers
forced layout operations
Links
Presentation slides: http://1drv.ms/1JZlYLc

Session feedback: http://oreil.ly/1Fkh2ej
Build Session on Web Runtime Performance:
o http://channel9.msdn.com/events/Build/2013/3-068
(Modify/Readback pattern at 57:00)
Google Developer Links:

o https://developers.google.com/web/fundamentals/perfo
rmance/rendering/avoid-large-complex-layouts-andlayout-thrashing?hl=en
o https://developers.google.com/speed/articles/reflow
o https://developer.chrome.com/devtools/docs/timeline

Building The Fast New MSN

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Building The Fast New MSN

Încărcat de

Drepturi de autor:

Formate disponibile

Building the Fast New MSN.

Entire stack on Azure PaaS

Single jQuery URL

Above Fold Content: 250KB

Hero Image Render

Network isnt always the bottleneck

Looking at the waterfall isnt enough

CPU cycles spent on

Forced Layout Operations:

Sequence of two actions necessary for a

1. Modify: Invalidating a section of the

Small, seemingly harmless DOM

What to look for

Batch writes together

Basic: Bake in common best practices

Intermediate: Incorporate relevant newer

Presentation slides: http://1drv.ms/1JZlYLc

Google Developer Links:

S-ar putea să vă placă și