-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixes for TTFB #2231
fixes for TTFB #2231
Changes from 7 commits
830c4a1
28524ca
7018e81
c1425dd
830037c
afde577
efcf5c1
45171cd
56dab1a
f053799
ab8b571
8b06a37
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
/** | ||
* @license Copyright 2017 Google Inc. All Rights Reserved. | ||
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 | ||
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | ||
*/ | ||
'use strict'; | ||
|
||
const Audit = require('./audit'); | ||
const Util = require('../report/v2/renderer/util'); | ||
const URL = require('../lib/url-shim'); | ||
|
||
const TTFB_THRESHOLD = 200; | ||
const TTFB_THRESHOLD_BUFFER = 15; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. at this point I'm not sure splitting buffer is worth it when our threshold is 600, haha |
||
|
||
class TTFBMetric extends Audit { | ||
/** | ||
* @return {!AuditMeta} | ||
*/ | ||
static get meta() { | ||
return { | ||
category: 'Performance', | ||
name: 'time-to-first-byte', | ||
description: 'Time To First Byte (TTFB)', | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this description nicely summarizes what we're really doing but it feels weird along with the other perf opportunities, maybe we should convert it into something like "Keep server response times low" and mention TTFB in the description or debugString? I know @paulirish doesn't like "response time" though ;) open to whatever doesn't make it feel out of place there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Keep server response times low (TTFB)? |
||
informative: true, | ||
helpText: 'Time To First Byte identifies the time at which your server sends a response.' + | ||
'[Learn more](https://developers.google.com/web/tools/chrome-devtools/network-performance/issues).', | ||
requiredArtifacts: ['devtoolsLogs'] | ||
}; | ||
} | ||
|
||
static caclulateTTFB(record) { | ||
const timing = record._timing; | ||
|
||
return timing.receiveHeadersEnd - timing.sendEnd; | ||
} | ||
|
||
/** | ||
* @param {!Artifacts} artifacts | ||
* @return {!AuditResult} | ||
*/ | ||
static audit(artifacts) { | ||
const devtoolsLogs = artifacts.devtoolsLogs[Audit.DEFAULT_PASS]; | ||
|
||
return Promise.all([ | ||
artifacts.requestNetworkRecords(devtoolsLogs), | ||
artifacts.requestCriticalRequests(devtoolsLogs) | ||
]) | ||
.then(([networkRecords, criticalRequests]) => { | ||
const results = []; | ||
let displayValue; | ||
|
||
criticalRequests.forEach(request => { | ||
const networkRecord = networkRecords.find(record => record._requestId === request.id); | ||
|
||
if (networkRecord && networkRecord._timing) { | ||
const ttfb = TTFBMetric.caclulateTTFB(networkRecord); | ||
results.push({ | ||
url: URL.getURLDisplayName(networkRecord._url), | ||
ttfb: Util.formatMilliseconds(Math.round(ttfb), 1), | ||
rawTTFB: ttfb | ||
}); | ||
} | ||
}); | ||
|
||
const recordsOverBudget = results.filter(row => | ||
row.rawTTFB > TTFB_THRESHOLD + TTFB_THRESHOLD_BUFFER | ||
); | ||
|
||
if (recordsOverBudget.length) { | ||
const thresholdDisplay = Util.formatMiliseconds(TTFB_THRESHOLD, 1); | ||
const recordsOverBudgetDisplay = Util.formatNumber(recordsOverBudget.length); | ||
displayValue = `${recordsOverBudgetDisplay} critical request(s) went over` + | ||
` the ${thresholdDisplay} threshold`; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if it's over the threshold then we can be confident it took at least that amount of time, so let's report the actual ttfb here e.g. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yours sgtm too 👍 |
||
} | ||
|
||
const headings = [ | ||
{key: 'url', itemType: 'url', text: 'URL'}, | ||
{key: 'ttfb', itemType: 'text', text: 'Time To First Byte (ms)'}, | ||
]; | ||
|
||
return { | ||
rawValue: recordsOverBudget.length === 0, | ||
results, | ||
headings, | ||
displayValue, | ||
}; | ||
}); | ||
} | ||
} | ||
|
||
module.exports = TTFBMetric; |
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we intending to run this audit only on unthrottled runs? Won't it flag all resources with the default throttling settings on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe I don't understand this comment. TTFB should be below 200, this is merely a constant that I use in the audit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if throttling is on won't TTFB always be at least as high as our throttling value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a really good question. I believer you are right. Should we higher the max ttfb? I believe @paulirish suggested using 200ms
I'll do some audits based on throttling and no throttling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When throttling is the TTFB that we observe should be minimum 150ms. And if there was any server latency, that is just absorbed in there.
So if the observed TTFB is > 151ms, then ALL of that was real network latency + server response.
That much sound correct to yall?
Then, 200 is a number we can evaluate separate from our throttling and we just have to decide when its slow enough for us to care.
PSI uses either 200 or 400, I forget.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah based on https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/lib/emulation.js#L47 our set latency should be 562ms. So whatever i just say but s/150/562/ :)
well... then our threshold has to be like 600ms
eesh.