SlideShare une entreprise Scribd logo
1  sur  102
The Truth About Your
Web App’s Performance
John Riviello
@JohnRiv
Distinguished Engineer, Comcast Interactive Media
Web Conference at Penn State – June 22, 2015
John Riviello – The Truth Behind Your Web App’s Performance2
Frontend Performance Data
1. What do existing tools provide?
2. What data do you care about?
3. How do you gather that data?
4. What do you do with the data?
John Riviello – The Truth Behind Your Web App’s Performance3
1. Existing Tools
2. The Data You Care About
3. Gathering the Data
4. Analyzing the Data
Frontend Performance Data – Existing Tools
WebPagetest.org
John Riviello – The Truth Behind Your Web App’s Performance5
Frontend Performance Data – Existing Tools
http://www.sitespeed.io/
John Riviello – The Truth Behind Your Web App’s Performance11
Frontend Performance Data – Existing Tools
https://github.com/sitespeedio/grunt-sitespeedio
John Riviello – The Truth Behind Your Web App’s Performance16
Frontend Performance Data – Existing Tools
https://github.com/macbre/phantomas
https://github.com/gmetais/grunt-devperf
John Riviello – The Truth Behind Your Web App’s Performance17
http://yellowlab.tools/
Frontend Performance Data – Existing Tools
https://github.com/gmetais/grunt-yellowlabtools
John Riviello – The Truth Behind Your Web App’s Performance21
Frontend Performance Data – Existing Tools
John Riviello – The Truth Behind Your Web App’s Performance22
grunt.initConfig({
yellowlabtools: {
production: {
urls: [
'https://xtv.comcast.net'
],
failConditions: [
// The global score is the one calculated by Yellow Lab Tools
'fail if at least one url has a global score < 80/100',
// Every single rule has its own score
'fail if at least one url has a rule score < 50/100',
// You can ignore certain rules
'ignore iframesCount',
// You can check a metric instead of the score by omitting '/100'
'fail if at least one url has a domElementsCount > 2000'
]
}
}
});
Contribute to Open Source:
https://github.com/gmetais/YellowLabTools
"RUM" by Tom B is licensed under CC BY-NC-SA 2.0
Real
User
Monitoring
"yes, that's a rum filled coconut." by Brandon King is licensed under CC BY-NC 2.0 / Color adjusted from original
Frontend Performance Data – Existing Tools
John Riviello – The Truth Behind Your Web App’s Performance26
http://www.appdynamics.com/product/browser-real-user-monitoring/
http://docs.newrelic.com/docs/new-relic-browser/page-load-timing-process
https://ruxit.com/features/real-user-monitoring.html
https://www.pingdom.com/rum/
https://docs.newrelic.com/docs/browser/new-relic-browser/browser-agent-apis/manually-reporting-page-load-timing-data
1. Existing Tools
2. The Data You Care About
3. Gathering the Data
4. Analyzing the Data
Real
User
Monitoring
"yes, that's a rum filled coconut." by Brandon King is licensed under CC BY-NC 2.0 / Color adjusted from original
Illustration from http://www.w3.org/TR/navigation-timing/#processing-model
John Riviello – The Truth Behind Your Web App’s Performance36
Illustration from http://www.w3.org/TR/navigation-timing/#processing-model
John Riviello – The Truth Behind Your Web App’s Performance37
John Riviello – The Truth Behind Your Web App’s Performance39
John Riviello – The Truth Behind Your Web App’s Performance40
Frontend Performance Data – The Data You Care About
John Riviello – The Truth Behind Your Web App’s Performance41
Frontend Performance Data – The Data You Care About
Example Factors That Impact Performance:
John Riviello – The Truth Behind Your Web App’s Performance42
• User authentication state
•“Type” of user
• Number of “items” returned
• Flash SWF dependency
John Riviello – The Truth Behind Your Web App’s Performance43
http://mashable.com/2014/01/31/gmail-slow/
John Riviello – The Truth Behind Your Web App’s Performance44
“Gmail’s People Widget
appears to be the cause of
the sluggishness, which is,
only affecting Gmail on
the web Google
says…This is noticeable
when users open an email
conversation with a large
number of participants…”
Consider what other unique
factors in your app may
impact performance
1. Existing Tools
2. The Data You Care About
3. Gathering the Data
4. Analyzing the Data
John Riviello – The Truth Behind Your Web App’s Performance47
Frontend Performance Data – Gathering the Data
Marking Timestamps
John Riviello – The Truth Behind Your Web App’s Performance48
Back in the day:
> new Date().getTime();
1399754123456
ECMAScript 5.1:
> Date.now();
1399754123456
Most modern browsers have a better option…
Frontend Performance Data – Gathering the Data
W3C High Resolution Time
John Riviello – The Truth Behind Your Web App’s Performance50
•DOMHighResTimeStamp is available via
window.performance.now()
•Provides the time with sub-millisecond accuracy
•Measured relative to the navigationStart attribute
of the PerformanceTiming interface
•Not subject to system clock skew or adjustments
(uses a monotonically increasing clock)
Frontend Performance Data – Gathering the Data
W3C High Resolution Time – Sub-ms Example
John Riviello – The Truth Behind Your Web App’s Performance51
> var dateTest = function() {
var start = Date.now(),
area = window.innerWidth*window.innerHeight;
return Date.now() - start;
};
dateTest();
0
> var highResTest = function() {
var start = window.performance.now(),
area = window.innerWidth*window.innerHeight;
return window.performance.now() - start;
};
highResTest();
0.01200000406242907
Frontend Performance Data – Gathering the Data
W3C High Resolution Time – Monotonic Clock
John Riviello – The Truth Behind Your Web App’s Performance52
Why do we care?
“Most systems run a daemon which regularly
synchronizes the time. It is common for the clock to be
tweaked a few milliseconds every 15-20 minutes.
At that rate about 1% of 10 second intervals
measured would be inaccurate.”
Source: Tony Gentilcore
http://gent.ilcore.com/2012/06/better-timer-for-javascript.html
John Riviello – The Truth Behind Your Web App’s Performance53
John Riviello – The Truth Behind Your Web App’s Performance54
Browser Support
John Riviello – The Truth Behind Your Web App’s Performance61
John Riviello – The Truth Behind Your Web App’s Performance62
https://github.com/Comcast/Surf-N-Perf
User Timing
vs.
Surf-N-Perf
"Hurricane Earl's Waves" by John Riviello is licensed under CC BY-NC-SA 2.0 / Color adjusted from original
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Setting & Getting a Mark
John Riviello – The Truth Behind Your Web App’s Performance65
// User Timing API
> window.performance.mark('foo');
> window.performance.getEntriesByName('foo');
[PerformanceMark ]
duration: 0
entryType: "mark"
name: "foo"
startTime: 3323.620999988634
> window.performance.getEntriesByName('foo')[0].startTime;
3323.620999988634
// Surf-N-Perf
> surfnperf.mark('foo');
> surfnperf.getMark('foo');
3323.620999988634
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Navigation Timing Mark & User Mark Duration
John Riviello – The Truth Behind Your Web App’s Performance66
// User Timing API
> window.performance.mark('foo');
> window.performance.measure('page_load_to_foo', 'loadEventEnd',
'foo');
> window.performance.getEntriesByName('page_load_to_foo');
[PerformanceMeasure ]
duration: 3201.620999988634
entryType: "measure"
name: "page_load_to_foo"
startTime: 122
> window.performance.getEntriesByName('page_load_to_foo')[0].duration;
3201.620999988634
// Surf-N-Perf
> surfnperf.mark('foo');
> surfnperf.duration('loadEventEnd','foo');
3202
> surfnperf.duration('loadEventEnd','foo',{decimalPlaces:3});
3201.621
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Event Duration (i.e. 2 User Marks)
John Riviello – The Truth Behind Your Web App’s Performance67
// User Timing API
> window.performance.mark('barStart');
> window.performance.mark('barEnd');
> window.performance.measure('barEvent', 'barStart', 'barEnd');
> window.performance.getEntriesByName(’barEvent')[0].duration;
3512.499000004027
// Surf-N-Perf
> surfnperf.eventStart('bar');
> surfnperf.eventEnd('bar');
> surfnperf.eventDuration('bar');
3512
> surfnperf.eventDuration('bar',{decimalPlaces:12});
3512.499000004027
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Custom Event Data
John Riviello – The Truth Behind Your Web App’s Performance68
// Surf-N-Perf
> surfnperf.eventStart('bar');
// surfnperf.eventEnd(KEY, CUSTOM_DATA_OBJECT);
> surfnperf.eventEnd('bar', {baz:'qux'});
> surfnperf.getEventData('bar', 'baz');
"qux"
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Tying It Together with Backbone.fetch()
John Riviello – The Truth Behind Your Web App’s Performance69
// Surf-N-Perf
> var collection = new Backbone.Collection();
collection.url = '/get-data/';
surfnperf.eventStart('getData');
collection.fetch({
success: function(collection) {
surfnperf.eventEnd('getData', {status:'success', items: collection.length});
},
error: function() {
surfnperf.eventEnd('getData', {status:'error'});
},
});
> surfnperf.eventDuration('getData', {decimalPlaces:2});
1464.75
> surfnperf.getEventData('getData', 'status');
"success"
> surfnperf.getEventData('getData', 'items');
33
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Custom Data (not tied to an event)
John Riviello – The Truth Behind Your Web App’s Performance70
// Surf-N-Perf
> surfnperf.setCustom('initialUrl', window.location.pathname);
> surfnperf.getCustom('initialUrl');
"https://xtv.comcast.net/recent"
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance71
// Surf-N-Perf
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance72
> surfnperf.getNetworkTime(); // fetchStart to connectEnd
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance73
> surfnperf.getServerTime(); // requestStart to responseEnd
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance74
> surfnperf.getNetworkLatency(); // fetchStart to responseEnd
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance75
> surfnperf.getProcessingLoadTime(); // responseEnd to loadEventEnd
Frontend Performance Data – Gathering the Data with Surf-N-Perf
Common Navigation Timing Measurements
John Riviello – The Truth Behind Your Web App’s Performance76
> surfnperf.getFullRequestLoadTime(); // navigationStart to
loadEventEnd
1. Existing Tools
2. The Data You Care About
3. Gathering the Data
4. Analyzing the Data
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance78
Average Response Times
are for
Average Products
PERCENTILE
(at a minimum)
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance81
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance82
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance83
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance84
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance85
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance86
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance87
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance88
Frontend Performance Data – Analyzing The Data
John Riviello – The Truth Behind Your Web App’s Performance89
Frontend Performance Data – The Future
Time to First Paint
John Riviello – The Truth Behind Your Web App’s Performance91
Internet Explorer:
> window.performance.timing.msFirstPaint;
1434341969277
Google Chrome:
> window.chrome.loadTimes();
Object {
commitLoadTime: 1434341655.700179
connectionInfo: "http/1"
finishDocumentLoadTime: 1434341656.208713
finishLoadTime: 1434341656.733739 ...
Frontend Performance Data – The Future
Time to First Paint
John Riviello – The Truth Behind Your Web App’s Performance92
Google Chrome (continued):
firstPaintAfterLoadTime: 1434341657.201959
firstPaintTime: 1434341655.978471
navigationType: "Other"
npnNegotiatedProtocol: "unknown"
requestTime: 1434341655.141803
startLoadTime: 1434341655.570092
wasAlternateProtocolAvailable: false
wasFetchedViaSpdy: false
wasNpnNegotiated: false
}
Frontend Performance Data – The Future
Time to First Paint
John Riviello – The Truth Behind Your Web App’s Performance93
Alternatives:
-window.requestAnimationFrame()
- Load of last non-async resource in <head>
- Custom Metric (First Tweet, Hero Image, etc.)
http://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/
Frontend Performance Data – The Future
John Riviello – The Truth Behind Your Web App’s Performance95
Illustration from http://www.w3.org/TR/resource-timing/#processing-model
window.performance.getEntriesByType("resource")
Frontend Performance Data – The Future
John Riviello – The Truth Behind Your Web App’s Performance96
3rd Party Resource
Frontend Performance Data – The Future
John Riviello – The Truth Behind Your Web App’s Performance97
3rd Party Resource with Timing-Allow-Origin: *
Recap
Frontend Performance Data – Recap
John Riviello – The Truth Behind Your Web App’s Performance102
• Performance is a feature!
• Measure first—at the 99th percentile
• Leverage W3C Performance APIs
• Log network latency, browser processing time, and
the full webpage request & response
• Log major app-specific events with details
For Further Info & Feedback:
Twitter: @JohnRiv
GitHub: https://github.com/Comcast/Surf-N-Perf
SpeakerRate: http://spkr8.com/t/60261

Contenu connexe

En vedette

2013 04 rca_foresight
2013 04 rca_foresight2013 04 rca_foresight
2013 04 rca_foresight
Duncan Wilson
 
Time, frequency and social media
Time, frequency and social mediaTime, frequency and social media
Time, frequency and social media
Tomoya Shoji
 
Industrial trainingsoftware 2011
Industrial trainingsoftware 2011Industrial trainingsoftware 2011
Industrial trainingsoftware 2011
dkhari
 
YouthBuild's 30th Anniversary
YouthBuild's 30th AnniversaryYouthBuild's 30th Anniversary
YouthBuild's 30th Anniversary
youthbuildusa
 
Analyzing &amp; Converting Organic Search Traffic
Analyzing &amp; Converting Organic Search TrafficAnalyzing &amp; Converting Organic Search Traffic
Analyzing &amp; Converting Organic Search Traffic
jtreiber
 

En vedette (16)

2013 04 rca_foresight
2013 04 rca_foresight2013 04 rca_foresight
2013 04 rca_foresight
 
Avalon Cosmetics Inc Pp
Avalon Cosmetics Inc PpAvalon Cosmetics Inc Pp
Avalon Cosmetics Inc Pp
 
Yesterdays Gone...Whats Your Tommorrow
Yesterdays Gone...Whats Your TommorrowYesterdays Gone...Whats Your Tommorrow
Yesterdays Gone...Whats Your Tommorrow
 
CéGtaláLó éS CéGbank
CéGtaláLó éS CéGbankCéGtaláLó éS CéGbank
CéGtaláLó éS CéGbank
 
Team C presentation - Tresure Hunt Pudong, 05.04.09
Team C presentation - Tresure Hunt Pudong, 05.04.09Team C presentation - Tresure Hunt Pudong, 05.04.09
Team C presentation - Tresure Hunt Pudong, 05.04.09
 
2013 05 eu_iot
2013 05 eu_iot2013 05 eu_iot
2013 05 eu_iot
 
Presentazione Suggerimenti Marketing Fedele Srl
Presentazione Suggerimenti Marketing Fedele SrlPresentazione Suggerimenti Marketing Fedele Srl
Presentazione Suggerimenti Marketing Fedele Srl
 
Time, frequency and social media
Time, frequency and social mediaTime, frequency and social media
Time, frequency and social media
 
Industrial trainingsoftware 2011
Industrial trainingsoftware 2011Industrial trainingsoftware 2011
Industrial trainingsoftware 2011
 
New energy technologies
New energy technologiesNew energy technologies
New energy technologies
 
Chicora Introduction
Chicora IntroductionChicora Introduction
Chicora Introduction
 
EnèMics Interns De L’Emprenedor
EnèMics Interns De L’EmprenedorEnèMics Interns De L’Emprenedor
EnèMics Interns De L’Emprenedor
 
YouthBuild's 30th Anniversary
YouthBuild's 30th AnniversaryYouthBuild's 30th Anniversary
YouthBuild's 30th Anniversary
 
Analyzing &amp; Converting Organic Search Traffic
Analyzing &amp; Converting Organic Search TrafficAnalyzing &amp; Converting Organic Search Traffic
Analyzing &amp; Converting Organic Search Traffic
 
Dealing With Requests For Hastened Death (Handout)
Dealing With Requests For Hastened Death (Handout)Dealing With Requests For Hastened Death (Handout)
Dealing With Requests For Hastened Death (Handout)
 
Intro to distance (short)
Intro to distance (short)Intro to distance (short)
Intro to distance (short)
 

Similaire à The Truth About Your Web App's Performance

Rum first london web perf meetup
Rum first   london web perf meetupRum first   london web perf meetup
Rum first london web perf meetup
Cliff Crocker
 
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
NETWAYS
 

Similaire à The Truth About Your Web App's Performance (20)

The Truth About Your Web App's Performance
The Truth About Your Web App's PerformanceThe Truth About Your Web App's Performance
The Truth About Your Web App's Performance
 
Measuring web performance
Measuring web performanceMeasuring web performance
Measuring web performance
 
Client-Side Performance Monitoring (MobileTea, Rome)
Client-Side Performance Monitoring (MobileTea, Rome)Client-Side Performance Monitoring (MobileTea, Rome)
Client-Side Performance Monitoring (MobileTea, Rome)
 
DevOps: Find Solutions, Not More Defects
DevOps: Find Solutions, Not More DefectsDevOps: Find Solutions, Not More Defects
DevOps: Find Solutions, Not More Defects
 
Rum first london web perf meetup
Rum first   london web perf meetupRum first   london web perf meetup
Rum first london web perf meetup
 
BP204 - Take a REST and put your data to work with APIs!
BP204 - Take a REST and put your data to work with APIs!BP204 - Take a REST and put your data to work with APIs!
BP204 - Take a REST and put your data to work with APIs!
 
Building Multi-Tenant and SaaS products in PHP - CloudConf 2015
Building Multi-Tenant and SaaS products in PHP - CloudConf 2015Building Multi-Tenant and SaaS products in PHP - CloudConf 2015
Building Multi-Tenant and SaaS products in PHP - CloudConf 2015
 
improving the performance of Rails web Applications
improving the performance of Rails web Applicationsimproving the performance of Rails web Applications
improving the performance of Rails web Applications
 
GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale
GDD Japan 2009 - Designing OpenSocial Apps For Speed and ScaleGDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale
GDD Japan 2009 - Designing OpenSocial Apps For Speed and Scale
 
Synthetic Monitoring Deep Dive - AppSphere16
Synthetic Monitoring Deep Dive - AppSphere16Synthetic Monitoring Deep Dive - AppSphere16
Synthetic Monitoring Deep Dive - AppSphere16
 
Desenvolvendo uma aplicação híbrida para Android e IOs utilizando Ionic, aces...
Desenvolvendo uma aplicação híbrida para Android e IOs utilizando Ionic, aces...Desenvolvendo uma aplicação híbrida para Android e IOs utilizando Ionic, aces...
Desenvolvendo uma aplicação híbrida para Android e IOs utilizando Ionic, aces...
 
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
OSMC 2016 | Application Performance Management with Open-Source-Tooling by Ma...
 
OSMC 2016 - Application Performance Management with Open-Source-Tooling by M...
OSMC 2016 -  Application Performance Management with Open-Source-Tooling by M...OSMC 2016 -  Application Performance Management with Open-Source-Tooling by M...
OSMC 2016 - Application Performance Management with Open-Source-Tooling by M...
 
GlobalLogic Test Automation Online TechTalk “Playwright — A New Hope”
GlobalLogic Test Automation Online TechTalk “Playwright — A New Hope”GlobalLogic Test Automation Online TechTalk “Playwright — A New Hope”
GlobalLogic Test Automation Online TechTalk “Playwright — A New Hope”
 
Costruire applicazioni multi-tenant e piattaforme SaaS in PHP con Innomatic
Costruire applicazioni multi-tenant e piattaforme SaaS in PHP con InnomaticCostruire applicazioni multi-tenant e piattaforme SaaS in PHP con Innomatic
Costruire applicazioni multi-tenant e piattaforme SaaS in PHP con Innomatic
 
Forensic tools for in-depth performance investigations
Forensic tools for in-depth performance investigations Forensic tools for in-depth performance investigations
Forensic tools for in-depth performance investigations
 
Forensic Tools for In-Depth Performance Investigations
Forensic Tools for In-Depth Performance InvestigationsForensic Tools for In-Depth Performance Investigations
Forensic Tools for In-Depth Performance Investigations
 
Make It Fast - Using Modern Browser Performance APIs to Monitor and Improve t...
Make It Fast - Using Modern Browser Performance APIs to Monitor and Improve t...Make It Fast - Using Modern Browser Performance APIs to Monitor and Improve t...
Make It Fast - Using Modern Browser Performance APIs to Monitor and Improve t...
 
High Availability by Design
High Availability by DesignHigh Availability by Design
High Availability by Design
 
Measuring performance - Velocity 2016 Training
Measuring performance - Velocity 2016 TrainingMeasuring performance - Velocity 2016 Training
Measuring performance - Velocity 2016 Training
 

Plus de John Riviello

Plus de John Riviello (11)

The Decision Buy-In Algorithm
The Decision Buy-In AlgorithmThe Decision Buy-In Algorithm
The Decision Buy-In Algorithm
 
Future-Proofing Your JavaScript Framework Decision
Future-Proofing Your JavaScript Framework DecisionFuture-Proofing Your JavaScript Framework Decision
Future-Proofing Your JavaScript Framework Decision
 
Introduction to Web Components & Polymer Workshop - JS Interactive
Introduction to Web Components & Polymer Workshop - JS InteractiveIntroduction to Web Components & Polymer Workshop - JS Interactive
Introduction to Web Components & Polymer Workshop - JS Interactive
 
Web Components: The Future of Web Development is Here
Web Components: The Future of Web Development is HereWeb Components: The Future of Web Development is Here
Web Components: The Future of Web Development is Here
 
The Critical Career Path Conversation
The Critical Career Path ConversationThe Critical Career Path Conversation
The Critical Career Path Conversation
 
Ensuring Design Standards with Web Components
Ensuring Design Standards with Web ComponentsEnsuring Design Standards with Web Components
Ensuring Design Standards with Web Components
 
Introduction to Web Components & Polymer Workshop - U of I WebCon
Introduction to Web Components & Polymer Workshop - U of I WebConIntroduction to Web Components & Polymer Workshop - U of I WebCon
Introduction to Web Components & Polymer Workshop - U of I WebCon
 
Web Components: The Future of Web Development is Here
Web Components: The Future of Web Development is HereWeb Components: The Future of Web Development is Here
Web Components: The Future of Web Development is Here
 
Polymer-Powered Design Systems - DevFest Florida
Polymer-Powered Design Systems - DevFest FloridaPolymer-Powered Design Systems - DevFest Florida
Polymer-Powered Design Systems - DevFest Florida
 
Workshop: Introduction to Web Components & Polymer
Workshop: Introduction to Web Components & Polymer Workshop: Introduction to Web Components & Polymer
Workshop: Introduction to Web Components & Polymer
 
Custom Elements with Polymer Web Components #econfpsu16
Custom Elements with Polymer Web Components #econfpsu16Custom Elements with Polymer Web Components #econfpsu16
Custom Elements with Polymer Web Components #econfpsu16
 

Dernier

%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
masabamasaba
 
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
VictoriaMetrics
 
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
Health
 
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
Medical / Health Care (+971588192166) Mifepristone and Misoprostol tablets 200mg
 

Dernier (20)

Artyushina_Guest lecture_YorkU CS May 2024.pptx
Artyushina_Guest lecture_YorkU CS May 2024.pptxArtyushina_Guest lecture_YorkU CS May 2024.pptx
Artyushina_Guest lecture_YorkU CS May 2024.pptx
 
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
 
%in Rustenburg+277-882-255-28 abortion pills for sale in Rustenburg
%in Rustenburg+277-882-255-28 abortion pills for sale in Rustenburg%in Rustenburg+277-882-255-28 abortion pills for sale in Rustenburg
%in Rustenburg+277-882-255-28 abortion pills for sale in Rustenburg
 
WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Arch...
WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Arch...WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Arch...
WSO2CON 2024 - Cloud Native Middleware: Domain-Driven Design, Cell-Based Arch...
 
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
 
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
 
VTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learnVTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learn
 
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
 
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
 
%in ivory park+277-882-255-28 abortion pills for sale in ivory park
%in ivory park+277-882-255-28 abortion pills for sale in ivory park %in ivory park+277-882-255-28 abortion pills for sale in ivory park
%in ivory park+277-882-255-28 abortion pills for sale in ivory park
 
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
+971565801893>>SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHAB...
 
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
Abortion Pill Prices Tembisa [(+27832195400*)] 🏥 Women's Abortion Clinic in T...
 
WSO2CON2024 - It's time to go Platformless
WSO2CON2024 - It's time to go PlatformlessWSO2CON2024 - It's time to go Platformless
WSO2CON2024 - It's time to go Platformless
 
tonesoftg
tonesoftgtonesoftg
tonesoftg
 
%in Harare+277-882-255-28 abortion pills for sale in Harare
%in Harare+277-882-255-28 abortion pills for sale in Harare%in Harare+277-882-255-28 abortion pills for sale in Harare
%in Harare+277-882-255-28 abortion pills for sale in Harare
 
%in Benoni+277-882-255-28 abortion pills for sale in Benoni
%in Benoni+277-882-255-28 abortion pills for sale in Benoni%in Benoni+277-882-255-28 abortion pills for sale in Benoni
%in Benoni+277-882-255-28 abortion pills for sale in Benoni
 
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital TransformationWSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
 
%in Midrand+277-882-255-28 abortion pills for sale in midrand
%in Midrand+277-882-255-28 abortion pills for sale in midrand%in Midrand+277-882-255-28 abortion pills for sale in midrand
%in Midrand+277-882-255-28 abortion pills for sale in midrand
 
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
 
%in tembisa+277-882-255-28 abortion pills for sale in tembisa
%in tembisa+277-882-255-28 abortion pills for sale in tembisa%in tembisa+277-882-255-28 abortion pills for sale in tembisa
%in tembisa+277-882-255-28 abortion pills for sale in tembisa
 

The Truth About Your Web App's Performance

  • 1. The Truth About Your Web App’s Performance John Riviello @JohnRiv Distinguished Engineer, Comcast Interactive Media Web Conference at Penn State – June 22, 2015
  • 2. John Riviello – The Truth Behind Your Web App’s Performance2
  • 3. Frontend Performance Data 1. What do existing tools provide? 2. What data do you care about? 3. How do you gather that data? 4. What do you do with the data? John Riviello – The Truth Behind Your Web App’s Performance3
  • 4. 1. Existing Tools 2. The Data You Care About 3. Gathering the Data 4. Analyzing the Data
  • 5. Frontend Performance Data – Existing Tools WebPagetest.org John Riviello – The Truth Behind Your Web App’s Performance5
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11. Frontend Performance Data – Existing Tools http://www.sitespeed.io/ John Riviello – The Truth Behind Your Web App’s Performance11
  • 12.
  • 13.
  • 14.
  • 15.
  • 16. Frontend Performance Data – Existing Tools https://github.com/sitespeedio/grunt-sitespeedio John Riviello – The Truth Behind Your Web App’s Performance16
  • 17. Frontend Performance Data – Existing Tools https://github.com/macbre/phantomas https://github.com/gmetais/grunt-devperf John Riviello – The Truth Behind Your Web App’s Performance17
  • 18.
  • 20.
  • 21. Frontend Performance Data – Existing Tools https://github.com/gmetais/grunt-yellowlabtools John Riviello – The Truth Behind Your Web App’s Performance21
  • 22. Frontend Performance Data – Existing Tools John Riviello – The Truth Behind Your Web App’s Performance22 grunt.initConfig({ yellowlabtools: { production: { urls: [ 'https://xtv.comcast.net' ], failConditions: [ // The global score is the one calculated by Yellow Lab Tools 'fail if at least one url has a global score < 80/100', // Every single rule has its own score 'fail if at least one url has a rule score < 50/100', // You can ignore certain rules 'ignore iframesCount', // You can check a metric instead of the score by omitting '/100' 'fail if at least one url has a domElementsCount > 2000' ] } } });
  • 23. Contribute to Open Source: https://github.com/gmetais/YellowLabTools
  • 24. "RUM" by Tom B is licensed under CC BY-NC-SA 2.0
  • 25. Real User Monitoring "yes, that's a rum filled coconut." by Brandon King is licensed under CC BY-NC 2.0 / Color adjusted from original
  • 26. Frontend Performance Data – Existing Tools John Riviello – The Truth Behind Your Web App’s Performance26
  • 32. 1. Existing Tools 2. The Data You Care About 3. Gathering the Data 4. Analyzing the Data
  • 33. Real User Monitoring "yes, that's a rum filled coconut." by Brandon King is licensed under CC BY-NC 2.0 / Color adjusted from original
  • 34.
  • 35.
  • 36. Illustration from http://www.w3.org/TR/navigation-timing/#processing-model John Riviello – The Truth Behind Your Web App’s Performance36
  • 37. Illustration from http://www.w3.org/TR/navigation-timing/#processing-model John Riviello – The Truth Behind Your Web App’s Performance37
  • 38.
  • 39. John Riviello – The Truth Behind Your Web App’s Performance39
  • 40. John Riviello – The Truth Behind Your Web App’s Performance40
  • 41. Frontend Performance Data – The Data You Care About John Riviello – The Truth Behind Your Web App’s Performance41
  • 42. Frontend Performance Data – The Data You Care About Example Factors That Impact Performance: John Riviello – The Truth Behind Your Web App’s Performance42 • User authentication state •“Type” of user • Number of “items” returned • Flash SWF dependency
  • 43. John Riviello – The Truth Behind Your Web App’s Performance43
  • 44. http://mashable.com/2014/01/31/gmail-slow/ John Riviello – The Truth Behind Your Web App’s Performance44 “Gmail’s People Widget appears to be the cause of the sluggishness, which is, only affecting Gmail on the web Google says…This is noticeable when users open an email conversation with a large number of participants…”
  • 45. Consider what other unique factors in your app may impact performance
  • 46. 1. Existing Tools 2. The Data You Care About 3. Gathering the Data 4. Analyzing the Data
  • 47. John Riviello – The Truth Behind Your Web App’s Performance47
  • 48. Frontend Performance Data – Gathering the Data Marking Timestamps John Riviello – The Truth Behind Your Web App’s Performance48 Back in the day: > new Date().getTime(); 1399754123456 ECMAScript 5.1: > Date.now(); 1399754123456 Most modern browsers have a better option…
  • 49.
  • 50. Frontend Performance Data – Gathering the Data W3C High Resolution Time John Riviello – The Truth Behind Your Web App’s Performance50 •DOMHighResTimeStamp is available via window.performance.now() •Provides the time with sub-millisecond accuracy •Measured relative to the navigationStart attribute of the PerformanceTiming interface •Not subject to system clock skew or adjustments (uses a monotonically increasing clock)
  • 51. Frontend Performance Data – Gathering the Data W3C High Resolution Time – Sub-ms Example John Riviello – The Truth Behind Your Web App’s Performance51 > var dateTest = function() { var start = Date.now(), area = window.innerWidth*window.innerHeight; return Date.now() - start; }; dateTest(); 0 > var highResTest = function() { var start = window.performance.now(), area = window.innerWidth*window.innerHeight; return window.performance.now() - start; }; highResTest(); 0.01200000406242907
  • 52. Frontend Performance Data – Gathering the Data W3C High Resolution Time – Monotonic Clock John Riviello – The Truth Behind Your Web App’s Performance52 Why do we care? “Most systems run a daemon which regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.” Source: Tony Gentilcore http://gent.ilcore.com/2012/06/better-timer-for-javascript.html
  • 53. John Riviello – The Truth Behind Your Web App’s Performance53
  • 54. John Riviello – The Truth Behind Your Web App’s Performance54
  • 55.
  • 56.
  • 58.
  • 59.
  • 60.
  • 61. John Riviello – The Truth Behind Your Web App’s Performance61
  • 62. John Riviello – The Truth Behind Your Web App’s Performance62
  • 64. User Timing vs. Surf-N-Perf "Hurricane Earl's Waves" by John Riviello is licensed under CC BY-NC-SA 2.0 / Color adjusted from original
  • 65. Frontend Performance Data – Gathering the Data with Surf-N-Perf Setting & Getting a Mark John Riviello – The Truth Behind Your Web App’s Performance65 // User Timing API > window.performance.mark('foo'); > window.performance.getEntriesByName('foo'); [PerformanceMark ] duration: 0 entryType: "mark" name: "foo" startTime: 3323.620999988634 > window.performance.getEntriesByName('foo')[0].startTime; 3323.620999988634 // Surf-N-Perf > surfnperf.mark('foo'); > surfnperf.getMark('foo'); 3323.620999988634
  • 66. Frontend Performance Data – Gathering the Data with Surf-N-Perf Navigation Timing Mark & User Mark Duration John Riviello – The Truth Behind Your Web App’s Performance66 // User Timing API > window.performance.mark('foo'); > window.performance.measure('page_load_to_foo', 'loadEventEnd', 'foo'); > window.performance.getEntriesByName('page_load_to_foo'); [PerformanceMeasure ] duration: 3201.620999988634 entryType: "measure" name: "page_load_to_foo" startTime: 122 > window.performance.getEntriesByName('page_load_to_foo')[0].duration; 3201.620999988634 // Surf-N-Perf > surfnperf.mark('foo'); > surfnperf.duration('loadEventEnd','foo'); 3202 > surfnperf.duration('loadEventEnd','foo',{decimalPlaces:3}); 3201.621
  • 67. Frontend Performance Data – Gathering the Data with Surf-N-Perf Event Duration (i.e. 2 User Marks) John Riviello – The Truth Behind Your Web App’s Performance67 // User Timing API > window.performance.mark('barStart'); > window.performance.mark('barEnd'); > window.performance.measure('barEvent', 'barStart', 'barEnd'); > window.performance.getEntriesByName(’barEvent')[0].duration; 3512.499000004027 // Surf-N-Perf > surfnperf.eventStart('bar'); > surfnperf.eventEnd('bar'); > surfnperf.eventDuration('bar'); 3512 > surfnperf.eventDuration('bar',{decimalPlaces:12}); 3512.499000004027
  • 68. Frontend Performance Data – Gathering the Data with Surf-N-Perf Custom Event Data John Riviello – The Truth Behind Your Web App’s Performance68 // Surf-N-Perf > surfnperf.eventStart('bar'); // surfnperf.eventEnd(KEY, CUSTOM_DATA_OBJECT); > surfnperf.eventEnd('bar', {baz:'qux'}); > surfnperf.getEventData('bar', 'baz'); "qux"
  • 69. Frontend Performance Data – Gathering the Data with Surf-N-Perf Tying It Together with Backbone.fetch() John Riviello – The Truth Behind Your Web App’s Performance69 // Surf-N-Perf > var collection = new Backbone.Collection(); collection.url = '/get-data/'; surfnperf.eventStart('getData'); collection.fetch({ success: function(collection) { surfnperf.eventEnd('getData', {status:'success', items: collection.length}); }, error: function() { surfnperf.eventEnd('getData', {status:'error'}); }, }); > surfnperf.eventDuration('getData', {decimalPlaces:2}); 1464.75 > surfnperf.getEventData('getData', 'status'); "success" > surfnperf.getEventData('getData', 'items'); 33
  • 70. Frontend Performance Data – Gathering the Data with Surf-N-Perf Custom Data (not tied to an event) John Riviello – The Truth Behind Your Web App’s Performance70 // Surf-N-Perf > surfnperf.setCustom('initialUrl', window.location.pathname); > surfnperf.getCustom('initialUrl'); "https://xtv.comcast.net/recent"
  • 71. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance71 // Surf-N-Perf
  • 72. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance72 > surfnperf.getNetworkTime(); // fetchStart to connectEnd
  • 73. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance73 > surfnperf.getServerTime(); // requestStart to responseEnd
  • 74. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance74 > surfnperf.getNetworkLatency(); // fetchStart to responseEnd
  • 75. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance75 > surfnperf.getProcessingLoadTime(); // responseEnd to loadEventEnd
  • 76. Frontend Performance Data – Gathering the Data with Surf-N-Perf Common Navigation Timing Measurements John Riviello – The Truth Behind Your Web App’s Performance76 > surfnperf.getFullRequestLoadTime(); // navigationStart to loadEventEnd
  • 77. 1. Existing Tools 2. The Data You Care About 3. Gathering the Data 4. Analyzing the Data
  • 78. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance78
  • 79. Average Response Times are for Average Products
  • 81. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance81
  • 82. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance82
  • 83. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance83
  • 84. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance84
  • 85. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance85
  • 86. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance86
  • 87. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance87
  • 88. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance88
  • 89. Frontend Performance Data – Analyzing The Data John Riviello – The Truth Behind Your Web App’s Performance89
  • 90.
  • 91. Frontend Performance Data – The Future Time to First Paint John Riviello – The Truth Behind Your Web App’s Performance91 Internet Explorer: > window.performance.timing.msFirstPaint; 1434341969277 Google Chrome: > window.chrome.loadTimes(); Object { commitLoadTime: 1434341655.700179 connectionInfo: "http/1" finishDocumentLoadTime: 1434341656.208713 finishLoadTime: 1434341656.733739 ...
  • 92. Frontend Performance Data – The Future Time to First Paint John Riviello – The Truth Behind Your Web App’s Performance92 Google Chrome (continued): firstPaintAfterLoadTime: 1434341657.201959 firstPaintTime: 1434341655.978471 navigationType: "Other" npnNegotiatedProtocol: "unknown" requestTime: 1434341655.141803 startLoadTime: 1434341655.570092 wasAlternateProtocolAvailable: false wasFetchedViaSpdy: false wasNpnNegotiated: false }
  • 93. Frontend Performance Data – The Future Time to First Paint John Riviello – The Truth Behind Your Web App’s Performance93 Alternatives: -window.requestAnimationFrame() - Load of last non-async resource in <head> - Custom Metric (First Tweet, Hero Image, etc.) http://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/
  • 94.
  • 95. Frontend Performance Data – The Future John Riviello – The Truth Behind Your Web App’s Performance95 Illustration from http://www.w3.org/TR/resource-timing/#processing-model window.performance.getEntriesByType("resource")
  • 96. Frontend Performance Data – The Future John Riviello – The Truth Behind Your Web App’s Performance96 3rd Party Resource
  • 97. Frontend Performance Data – The Future John Riviello – The Truth Behind Your Web App’s Performance97 3rd Party Resource with Timing-Allow-Origin: *
  • 98.
  • 99.
  • 100.
  • 101. Recap
  • 102. Frontend Performance Data – Recap John Riviello – The Truth Behind Your Web App’s Performance102 • Performance is a feature! • Measure first—at the 99th percentile • Leverage W3C Performance APIs • Log network latency, browser processing time, and the full webpage request & response • Log major app-specific events with details For Further Info & Feedback: Twitter: @JohnRiv GitHub: https://github.com/Comcast/Surf-N-Perf SpeakerRate: http://spkr8.com/t/60261

Notes de l'éditeur

  1. Hello everyone. I'm John Riviello and I current work at Comcast in Philadelphia as the lead frontend developer for the customer entertainment websites As you can see I'm going to be talking about web app & website performance. Specifically I’m going to be discussing - What web performance data you should be gathering - How to gather that data, and - How to interpret & analyze that data so you can focus your efforts to improve your WEB APP’S PERFORMANCE on the areas that will provide the BIGGEST IMPACT to your users This talk is based on the work I did for a product known as X1 CloudTV.
  2. So to provide some quick background on the product, you may have already heard of X1, which is the newest set top box from Comcast. CloudTV is the ability to store your DVR recordings in the cloud, which is nice because you get more space and then you can stream those recordings to any device in the home, as well as download them to your iOS or Android devices. It also supports Live TV and On Demand content. The idea is to have the same experience across all your devices, and I was one of the developers working on the web experience. We ended up building it as a SINGLE PAGE APP so that you can continue to STREAM VIDEO while you perform other activities, just like you do on your TV. It uses BackboneJS on the frontend with ruby on the server side talking to a hypermedia API, but what I'm going to talk about applies to all single page apps regardless of framework, and websites as well. So we're essentially turning your web browser into a TV, which was a lot of fun to build. Since I was recreating the TV experience, I had to think about how people typically experience TV. Think about being at home. You sit on the couch, pickup your remote (or your smartphone or your smartwatch), and turn on your TV. What happens? (pause) Video starts playing immediately. In the sense of startup speeds, televisions have always been fast. The slowest aspect was when your old tube television had to warm up for a few seconds. So it’s pretty clear that the PERFORMANCE of the web app I was building is itself a FEATURE, and a very important one at that. But that’s not only the case for this app, it’s the case for any app or website, including yours. So I knew we had to make our web app fast, and in our quest to do so…
  3. …we've asked ourselves these questions that I'll be covering throughout this talk: What do existing tools provide? What data do you care about? How do you gather that data? What do you do with the data? Now before you can fulfill the super-specific requirement of "make it fast", you need to know: 1. how fast or slow your app currently is 2. a way to consistently monitor those metrics so that when you get a target either that you set or that is given to you, you can see your work helping (or not) and make sure you're focusing on the right things
  4. So let's start off by looking at some existing tools, of which there are many. I’m going to touch on a few of them…
  5. webpagetest.org - This tool was originally developed by AOL & then they open-sourced in and Google has since taken the reigns on it and done an excellent job
  6. - This provides some great data & suggestions - Get to see the performance of the page on first load and then a repeat view when assets are cached
  7. - You get a full waterfall showing in detail the timing information
  8. - There's the connection view which shows each TCP socket
  9. - You get a nice PageSpeed Optimization check with actions you can take to improve performance
  10. - But here's one spot where it falls a bit short: - I assure you that this is not what our app looks like when it is "Fully Loaded". This is of course a loading screen, which we want to display for as short of a time as possible, but we need to know when the app is actually ready to use to understand the actual performance - now, there is a way to fix that in some browsers, but I'll get into those details a little later
  11. If running your own metrics-collecting server with the help of Vagrant or Docker sounds like fun, then SiteSpeed.io provides all the details that WebPageTest does and much more, as well as support for custom metrics. (if that doesn’t, talk to the person in your organization that is into DevOps) You can deploy to various clouds (such as Digital Ocean) and collect data from different parts of the country & around the world 3 Docker images: One containing Graphite, one with Grafana and one running sitespeed.io. This allows you to collect metrics, store the data, and then graph them
  12. Here’s a peak at what it looks like. This is their dashboard that tracks WebPageTest runs over time
  13. It provides an overall summary of the site you’re testing over time by testing multiple URLs & fetching them every 30 minutes These boxes at the bottom are colored based on performance budgets that you can configure
  14. It will also provide metrics for an individual page
  15. It’s also setup to compare performance metrics across multiple sites so you can track your competitors …Also, it has the capability to add your own metrics and graph them
  16. One other great feature is it has a grunt plugin as well that will tell you if you’ve exceeded your performance budget
  17. Phantomas is another tool, with a much cooler name Which as you can see is a phantomJS-based web performance metrics collector and monitoring tool. I find it most valuable when used with a Continuous Integration server where you push new code, deploy it, and then run this tool so you get a history of performance related changes and can tie them to a commit. I'd recommend running it via grunt-devperf 1. The grunt integration makes for an easy setup, and 2. Phantomas provides a TON of data, and grunt-devperf has a nice initial opening screen that looks like this…
  18. to give you a high level overview of TimeToFirstByte, OnDOMReadyTIme, WindowOnLoadTime I'll switch over to my browser real quick to show you just how extensive these phantomas reports are [BROWSER]
  19. For a more overall, single-run, score-based report, the author of Grunt-DevPerf has released an amazing online tool called Yellow Lab Tools
  20. It gives you an overall score, and you can dig down into the specifics Let’s switch over to the browser again and take a look
  21. It has a grunt plugin as well, which is for running against a website in a CI environment (ideally a test or staging environment before deploying to production) So similar to sitespeed.io, it can fail the build based on your YellowLabTools scores
  22. I really love their grunt configuration since it uses natural language
  23. grunt-yellowlabtools is not currently capable of keeping an history but this is definitely something the author wants to work on in the next months! So for now you ideally would run both grunt-devperf and grunt-yellow-lab-tools The author’s plan is: - Adding the ability to send data to Graphite (which can then be called by Kibana for dashboard creation). - Then work on including history directly inside YellowLabTools, which should be followed by adding this to the grunt task too. - This is a lot of work, he needs help, so check it out and contribute! And this is very useful, but this has it's limitations as well. For one, no one is actually using PhantomJS to USE your web app different users may have different experiences, Tools such as Phantomas & WebPageTest provide what is known as “Synthetic Monitoring” because it doesn’t reference actual user data. In the case of Phantomas it’s phantomJS running on either your machine or some server you’ve setup, and for WebPageTest it’s run from one of their servers they maintain around the world. so what you really want is …
  24. RUM!!! I'm not actually talking about the booze, I'm actually talking about...
  25. Real user monitoring (Real User Measurement or Metrics) It's not the "M" that's important, it's the "REAL USER" part that is important So let’s talk about some services that provide that…
  26. There are lots of paid services to collect RUM data. I’ve listed a few of them here. You’ll find a lot of the same features with these. I’ve used or at least researched a good number of these, and I’ve learned that if you are a company that is going to offer Real User Monitoring, the FIRST feature you build looks something like this… (new slide)
  27. You’ll often find a main dashboard where the center of attention will be a world map, like this one from AppDynamics. If you’re a global product then that may make sense, but for someone like Comcast where I’m working on products for customers that are 100% based on the United States, these world graphs are rather uninteresting to me. The charts are around it are where the good data is, such as overall response times by Average or various percentiles
  28. Pretty much all provide a break down of the page load time over time. This graph from New Relic contains: Request Queuing Server Application Time Network Time DOM Processing Page Rendering time
  29. Since they’re collecting real client-side data, many of these services also offer JavaScript error reporting which is pretty nice, because building that on your own and presenting that in an easy-to-read format is a bit of a challenge… … but of course that is highlighted AFTER the amazing WORLD MAP VIEW here on Ruxit’s sales page
  30. You’ll also often get breakdowns by different technologies which can of course impact load times. Here on pingdom’s information page they break down mobile, tablet & desktop performance, As well as the performance for each browser… Of course, you’ll find all of that AFTER THE WORLD MAP
  31. New Relic and others also offer the ability to get around that issue of the fully loaded not actually being fully loaded be manually marking the spot that your app is “fully loaded”
  32. OK so now we know about some existing tools, so let's talk about the data you care about
  33. So again, we care about real users. And those services I just mentioned are useful, but they’re all paid services so you may not be using it, and if you are, there are some pieces of data I find it best to gather yourself to analyze What more could I possibly care about? Let's talk about a feature that Phantomas & these paid services rely on:
  34. And that is navigation timing, which is a recommendation from the W3C If you want to see what it is, open up your favorite web developer tools console And run “window.performance.timing”…
  35. and you'll get a bunch of numbers like this Now these are individual timestamps of various events of when a page was loaded by the browser And from those, we can calculate what was going on at different points of that http request
  36. This illustration from the W3C spec explains that flow nicely. So you can see that covers: - unloading any previous document - checking HTML5 Application Cache - the DNS lookup, and - TCP handshake - then we get to the actual HTTP request - which is followed by the server actually responding - and then various DOM events as the document is built until finally, - the onLoad event fires This is some super useful stuff. You can take a wider view…
  37. and see how this provides info on: - Network Latency - Processing Time and those make up the majority of the - Full HTTP Request But then of course, there's this:...
  38. The app may not actually be usable when the onLoad event fires...
  39. so you need to account for that loading screen time...
  40. and mark the end of it so you can determine how long the loading screen is displayed And if you do gather that data, you can build nice charts…
  41. like this one that show the breakdown of Network Latency, Processing Time and the Loading Screen time But there are a bunch of things that could be affecting those response times & they really can't be represented in just one graph So let's talk about some of those
  42. - User authentication state [CLICK THROUGH!] - signed in users most likely will be loading more data than users that are not signed in - “Type” of user - once a user is signed in, there may be different types of users - For example, in our app, you may or may not have DVR - you may subscribe to certain premium networks - or you may have a bunch of parental controls configured - or for users not signed in, perhaps you're doing some A/B testing and segmenting users that way to deliver different experiences - Number of “items” returned - For example, if you do have a DVR, you could have - a couple recordings - or hundreds - or even a thousand - Also the number of channels will vary by region - SWF dependency - this is probably the case for those delivering video (other than HTML5 video) or games (which are the typical uses of Flash these days) - since flash is tied to video and that is so critical to the app, we handle some parts of authentication through a SWF file...
  43. Now that typically is embedded fairly quickly as I've pictured here, but it can bleed into the loading screen time
  44. Taking a step outside of the CloudTV app and looking elsewhere, here's an example of this happening with Gmail: Notice that in this case, Gmail was slow when these 3 factors were true: - the user had the people widget enabled - they were using the website (not a mobile app) - and they opened an email with a large number of participants So you can see, without that level of detail in your performance metrics, it's going to be MUCH more difficult to determine the cause of performance issues especially if it’s only affecting a certain portion of your user base
  45. So take a moment to consider what other unique factors in your app may impact performance
  46. OK so now that we know what data you want, how can we go about gathering that data if we don’t have access to one of those paid services, or we want more control of the data?
  47. So as I said, we need other marks, such as an "appReady" when the app is truly ready for user interaction So how do we mark that? ...
  48. - Back in the day we did this - ECMAscript 5.1 gave us Date.now() [shorter to write & faster to execute] - but most modern browsers have a better option...
  49. And that is High Resolution Time THAT SOUNDS COOL! What is it?
  50. [Read bullet points] Let's see why that is useful…
  51. First, the sub-millisecond accuracy I'm going to write a function using the old Date.now method that does something pretty simple, and you'll see it takes 0 milliseconds to complete! https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch6.md Some platforms don't have single millisecond precision, but instead only update the timer in larger increments. For example, older versions of windows (and thus IE) had only 15ms precision, which means the operation has to take at least that long for anything other than 0 to be reported! when I use High Resolution time, I get a crazy- accurate response The spec says it should be accurate to the thousandth of a millisecond. Some browsers are even more accurate, and some on Windows are only accurate to the millisecond, but they at least use the monotonic clock...
  52. Now as far as the Monotonic clock goes, let's go right to the person who reviewed the commit in chromium that added that for what that actually means: “Most systems run a daemon which regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.” So now we see the benefit of that
  53. It's also nice because now our appReady mark is the actual time for the full App to be ready. No math necessary! But to figure out the loading screen, we do need math. So we know we have the LoadEventEnd time, but loadEventEnd & appReady have different sources of 0 loadEventEnd = january 1, 1970 appReady = hopefully only a few seconds ago So we can't even do math with them
  54. so instead, we need to mark LoadEventEnd with a High Resolution timestamp when the page’s onload event fires, And then we have the same zero source so we can do math This is kind of a bummer, isn't it? Luckily, the W3C has realized this, and they're working on a new spec...
  55. called Navigation Timing Level 2 which uses the same zero source as High Resolution time and this will replace Navigation Timing Level 1 but it's still in a Draft state, so no one can take advantage of that yet bummer again But there is something else...
  56. and that's User Timing this is great for 2 reasons: - gives high resolution durations between user marks as well as a user mark and a navigation timing mark - webpagetest.org will not declare a document "fully loaded" until all user timing marks have been set Now, it’s not supported by all browsers, but there is a polyfill available so you can use the same methods, you just get limited functionality
  57. So with that in mind, let's talk about Browser Support
  58. As you can see, Navigation Timing Level 1 is in most modern browsers. IE added it back in Version 9.0 iOS Safari added it in 8.0, but in their 8.1 update, if you scroll to the very bottom of the release notes, they mentioned they removed it due to “performance issues”, which is ironic and unfortunate Luckily, it appears to be back in v9
  59. If we take a look at High Resolution Time, it’s the same for the current stable releases. IE didn't add it until Version 10, Android recently added it and again we have iOS teasing us with adding it in 8.0 and removing it in 8.1, but it’s back in 9.0 as well
  60. User Timing is even less support, Safari hasn’t implemented it in any version. Good news though the most recent stable release of Firefox adds support for User Timing
  61. So that means essentially for every mark you make, you need a standard timestamp and a high resolution one (if the browser supports it) and a User Timing mark to be able to get as much info as possible So if you mark - Page Start as soon as you possibly can (that is, basically as the first line of code after the opening head tag) - LoadEventEnd when the onLoad event fires - And "AppReady" when the app is ready...
  62. You can actually calculate your users' experience regardless of the browser their on BLUE = supports Navigation Timing RED = does not GREEN = all browsers Just make sure when you look at that data, you split it up by browser support So we do all of this in the CloudTV app. We: - set these marks and - do these calculations and - also log the info about the user and - the number of items returned by certain AJAX calls and - take browser support all into account, and and so on and so forth And when I went to do this work, I first searched for some open source project to handle all these inconsistencies and gather the extra data I needed, and I didn't find one that did that. So I opened sourced my library that handles that…
  63. It’s called Surf And Perf You can check it out on Comcast's GitHub page It’s available as an NPM module and also as a RUBY GEM for it so you can easily integrate it into Rails & other sprockets-based ruby web applications like Middleman This micro library will handle: - Marks - Events (start & end mark, as well as additional data such as success/failure & number of items) - Custom Data (e.g. user state) - Calculations for the durations and package it all up into a nice javascript object that you can then send to your servers to log
  64. Let’s talk about how to use Surf-N-Perf by comparing it to the User Timing API
  65. Now remember, Surf-N-Perf provides this functionality to all browsers using the best available API I’d like to show you how you would use the User Timing API in the browsers that support it vs using Surf-N-Perf To show how Surf-N-Perf makes it easier & more useful to set & get performance data Duration doesn’t make much sense here, but since a PerformanceMark extends the PerformanceEntry interface from the PerformanceTimeline spec (which is leveraged by the Navigation Timing & User Timing, among others, and that part of a PerformanceEntry, it’s always there for marks, and it’s always set to 0
  66. API for measure: window.performance.measure(MEASURE_NAME, MARK_1, MARK_2); - loadEventEnd -> the browser’s onload event fires Here the duration makes sense startTime is the first mark in the measure, which isn’t high-resolution time, but you do get a high-resolution duration
  67. We know how to do this based on what I’ve showed so far Create 2 marks Surf-N-Perf takes the concept of events & makes it easier surfnperf.eventStart('bar'); will mark that start for you
  68. Shifting to a few Surf-N-Perf-specific functions… We know how to do eventStart eventEnd actually takes an optional custom data object as its 2nd argument Then getEventData takes the event key as its 1st argument and the data you want as the 2nd An example of how we use this is to include the number of recordings a user has stored in their DVR
  69. // mark the start of the AJAX call // mark the end of the AJAX call, set its status to 'success' and the number of items returned as 'items’ // mark the end of the AJAX call, set its status to 'error'
  70. Takes a key & a value surfnperf.setCustom('initialUrl', window.location.pathname); Then you can get it by the key surfnperf.getCustom('initialUrl'); This is a relevant example, as time for the initial load of the app is based on what they requested, as the recent page will respond differently than the TV Grid, for example
  71. Surf-N-Perf also has helper methods for calculating common durations between navigation timing marks
  72. getNetworkTime(); // fetchStart to connectEnd
  73. getServerTime(); // requestStart to responseEnd
  74. getNetworkLatency(); // fetchStart to responseEnd Note it is NOT Network Time + Server Time, as there is usually a few milliseconds between connectEnd & requestStart
  75. getProcessingLoadTime(); // responseEnd to loadEventEnd responseEnd (or pageStart for older browsers)
  76. getFullRequestLoadTime(); // navigationStart to loadEventEnd navigationStart (or pageStart for older browsers) to loadEventEnd
  77. OK so now you have a bunch of real user performance data filling up your logs. So the question is what to do with it.
  78. We build various charts like this one I showed earlier using Splunk, but there are also Open Source tools such as - Graphite Kibana and Graylog2 that can generate similar charts from your logs, as well as splunk competitors such as Scalyr Now the Y-axis here is response time and the X-axis is time (by hour), but my question to you is, what do you think is the value to chart for each hour? One thing that may pop into your head is average response times, and I'd argue you don't want to chart that, or at the very least, that shouldn't be your primary focus. Why?
  79. Because Average response times are for average products And I know you don’t build average products, because you’re here at this conference, and you wouldn’t be here if you didn’t want to build the best products Think about it. If you say your app response in under a second on average, does that really sound good? Would you want the servers you host your web apps on, be it AWS or your own data center or dream host or whatever, to be up and running "on average" of course not, you want them always to be running that's why you hear that industry talk about stuff like five 9s uptime (meaning they're up 99.999 percent of the time, which is less than 1 hour of downtime a month) So what you want to focus on is..
  80. the 99 percentile And if your traffic is very large, you may want to even go further, to 3, 4 or 5 9s This way you're looking at what the VAST MAJORITY of your users are experiencing And if half are having a painful experience, staring at averages can mask that.
  81. So let's dig down more into the types of 99th percentile charts that we look at: - First you can see we break response time down not only by network latency, processing and the loading screen but we build a chart of each of those depending on what part of the app the user loads first RECENT, GRID, UNAUTH, OTHER
  82. - Here you can see how the number of recordings in a user's DVR can affect the response time of our API call for that
  83. - And here you can see how, interestingly, the number of channels does NOT appear to have an affect
  84. Now I mentioned earlier how we have this SWF that handles Auth, and it can bleed into the loading screen time. Now I've never actually seen that happen on my computer, but how do I know that happens? Here's the 99th percentile chart for that SWF
  85. And this chart compares it to the Loading Screen 99th percentile As you can see, they follow each other, With the SWF taking more time than the Loading Screen sometimes which means that to bring down the 99th percentile, we're going to need to focus on that AuthSWF
  86. A 95th percentile chart shows that we should see benefits there a well
  87. At 90th the relationship isn't as strong but it could help
  88. And then at 50th they're not that related So it's important to check a range of percentiles so you can estimate what the impact will be for a specific performance improvement Because although you want everyone to have a fast experience, you also want your performance tweaks to improve the most amount of users that are experiencing the bad performance issues
  89. And just to help show how averages aren't as useful, here is a chart comparing the auth swf average to the loading screen average. If I was just looking at that, I wouldn't have realized the impact of the AuthSWF IF NO TIME LEFT: 1-0-7-ENTER
  90. We have a few more minutes, so since the theme of the conference this year is DESIGN THE FUTURE, let’s talk about what we have to look forward to
  91. Internet Explorer actually has a metric for this It’s a timestamp measured in milliseconds from the Epoch Chrome also has a method called loadTimes() that includes a number of things…
  92. One of which is firstPaintTime Issues: Only supported in those 2 browsers May actually report first paint for a white screen
  93. Window.requestAnimationFrame() = requests that the browser call a specified function to update an animation before the next repaint. The argument of the callback function is a high-res timestamp It’s supported by IE10+, pretty much everything except for Opera Mini
  94. Resource Timing is another W3C performance working group spec, and this provides similar timing information for resources loaded by the main page
  95. This is accessible via window.performance.getEntriesByType(“resource”) So as you can see, you get: Redirect Time App Cache DNS TCP Request & Response times BUT, by default, this is only for resources loaded from the same origin… 3rd parties just provide this:
  96. All you get is the duration of the request, and in this case, that unfortunately is more than download time. It also includes “blocking time” - the delay between when the browser realizes it needs to download a resource to the time that it actually starts downloading the resource. Typically this happens when there are more resources than TCP connections (6-12, depending on the browser). Now, there is a way around this if 3rd-parties add a header:
  97. If a vendor adds that header, then you get the full picture. Only about 5% currently do, most notably, Google, Facebook, Disqus, and mPulse but this is growing. Also, this won’t be a big deal with HTTP/2 since you shouldn’t have to worry about blocking
  98. Even though it’s still a draft, a lot of browsers have adopted it already IE10 added it, Safari is the only modern desktop browser that doesn’t have it Mobile Safari & Opera mini don’t either
  99. There are 2 more specs I want to touch on real quickly before we wrap up The first is Server Timing This spec defines a special “Server-Timing” Header that the server can pass back on the request and include performance metrics from the server and those are exposed through window.performance.getEntries(). I think this is great because it provides even more detail into why your server requests took as long as they did and you can tie it all together with one log statement It’s an early draft, so the details will need to be debated & agreed upon by the browser vendors, but it’ll certainly be useful
  100. Lastly, there is Network Error Logging So this proposal does some of the work monitoring services do today. If a request is made and it can’t be completed due to “network reasons” (such as a failed DNS lookup, a connection timeout, or a reset connection), then the browser will ping your logging server with information about the error This works by specifying a Network Error Logging header on the request that includes the URL of your logging server
  101. TO RECAP:
  102. Please provide feedback online