Skip to content
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

core(audits): Link to Total Blocking Time documentation #9850

Merged
merged 2 commits into from
Oct 18, 2019
Merged

Conversation

kaycebasques
Copy link
Contributor

Summary

Links the Total Blocking Time report UI to its documentation on web.dev.

@kaycebasques kaycebasques changed the title Link to Total Blocking Time documentation core(audits): Link to Total Blocking Time documentation Oct 16, 2019
@@ -14,7 +14,7 @@ const UIStrings = {
title: 'Total Blocking Time',
/** Description of the Total Blocking Time (TBT) metric, which calculates the total duration of blocking time for a web page. Blocking times are time periods when the page would be blocked (prevented) from responding to user input (clicks, taps, and keypresses will feel slow to respond). This is displayed within a tooltip when the user hovers on the metric name to see more. No character length limits.*/
description: 'Sum of all time periods between FCP and Time to Interactive, ' +
'when task length exceeded 50ms, expressed in milliseconds.',
'when task length exceeded 50ms, expressed in milliseconds. [Learn more](https://web.dev/lighthouse-total-blocking-time).',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Article should be live soon

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kaycebasques is it likely that future articles will start having a lighthouse- prefix in their slug?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Philip is writing canonical docs for each metric 1 and it seems like those docs should get the high-profile URLs.

I would prefer the Lighthouse docs to go under web.dev/lighthouse/total-blocking-time (for example) but it seems like it may be a fair chunk of work for a minor cosmetic gain. cc @robdodson

1 GoogleChrome/web.dev#1639 (comment) explains why I think we should have Lighthouse docs for each metric in addition to Philip's canonical docs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer the Lighthouse docs to go under web.dev/lighthouse/total-blocking-time (for example) but it seems like it may be a fair chunk of work for a minor cosmetic gain. cc @robdodson

yeah we've avoided creating directories in our URLs because content is often in flux. Something might start off as a blog and then need to migrate to a section in /learn (which is what will happen with Phil's LCP. So, for the moment, we're using the same approach as css-tricks for their guides section. Everything hangs off of the root, and landing pages just collect those links.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

(I pushed the results of yarn update:sample-json)

@brendankenny
Copy link
Member

@googlebot I consent

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants