FID issues due to 3rd parties on click events are quite hard to troubleshoot so far and I am wondering if the web-vitals-extension HUD Overlay can store the previous page FID value to help spotting this kind of issues.

Below an example on Montblanc IT https://www.montblanc.com/it-it site where FID becomes 165ms but it's impossible for the user to notice that on the next page and it correlates with a 3rd party script Function Call.

Just scanned with deepscan.io and found this issue: https://deepscan.io/dashboard/#view=project&tid=9092&pid=11374&bid=168611&subview=issues&impact=%5B%22High%22%5D

Feedback from Phil:

I wouldn't show a green 0.00 for FID prior to the first input. I'd show a gray "--" or something like that since 0.00 is a valid value after an input, and seeing green is confusing.

The fix here will be only considering FID to be passing when it's state is final.

Feature request from #10

It would be useful for users to be able to close the overlay without having to disable it via options for a session.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Additional context
Add any other context or screenshots about the feature request here.

I am definitely a little concerned about folks loading this extension up on their high-powered machines, seeing LCP times in <1s range and then thinking the job is done on performance and/or distrusting other tooling that tells them their LCP is longer.

Example: cnn.com

On mobile this page takes ~8s for FCP and has horrendous performance, but on my laptop with wifi and an adblocker, this extension reports 0.8s, green all day. I'm worried that developers that use this extension on their own pages will visit under similarly rosy conditions and conclude the page is fast.

I'm not sure what the solution is other than a potential reminder that these metrics represent what you're observing on your device. Perhaps we could even run a little test or use ECT to say "your device looks like it's in the fastest 10%" or something and remind them it won't be typical of most users. Detecting adblockers might be another good caveat to place in there.

Not sure how much we can do here, but this was unexpected. If we can't improve the DX it should at least be documented.

1. Enable the HUD (overlay)
2. Load a page
3. Click anywhere in the HUD
4. FID becomes final

Describe the bug
When the extension is enabled and I am logged in on https://www.chromestatus.com/feature/5167290693713920, I cannot see the 'star', 'file a bug', or 'edit' buttons. Once I disabled the extension and refresh, I am able to see those buttons.

Version:

• OS w/ version: MacOS Catalina
• Browser w/ version Chrome 83

If I open a new tab in the background, and wait ~15 seconds before switching over to it, then LCP will be at least 15 seconds. From a UX perspective, the page appeared almost instantly, so a "slow" LCP value like this is not representative.

However, this seems to be a feature (not a bug) of the API because it's documented at web.dev/lcp:

Caution: Since users can open pages in a background tab, it's possible that the largest contentful paint will not happen until the user focuses the tab, which can be much later than when they first loaded it.

It'd be useful if this extension annotated LCP in some way to indicate that the value was inflated by the amount of time the page was in the background. If complete=true and active=false then the annotation would be useful. If needed we could also use the difference in time between complete=true and the activation change as a heuristic.

Should fix #46 (related to #44)

Describe the bug
Somehow instead of 00:25 we see 24:25 time.

To Reproduce
Open any website at 12pm.

Expected behavior
It should be 00:25 in (24h format) or 12:25 in (12h format)

Additional context, screenshots, screencasts

Badging as currently implemented has three states: in-determinant (grey), passing thresholds (green) and failing thresholds (red).

To complete ambient badging support, we want to support the following UX: overall green/red (current) which animates to a badge showing which metric is failing, and if there are multiple just show the number of metrics that are failing.

The states are as follows:

• 1 metric failing (animate between the overall status and what metric is failing)
• multiple metrics failing (animate between overall and this number of metrics)
• all metrics passing the thresholds (just green)

Approach I might suggest:

• Define an interval between showing the overall red/green status and animating to what metric is failing (e.g 2 seconds)
• Define a "stack" of what we are animating. e.g overall failing -> LCP failing -> CLS failing. If all three are failing perhaps just show the number 3 on a red tile. When the interval is reached update the badge icon and text accordingly.
• Tech wise, using static images for the icons may be the quickest approach. Dion did this for his individual extensions. An alternative is using <canvas>. Having tried this locally, I found it unnecessarily complex given the number of states we're working with. We can also play around with setBadgeText/backgroundcolor.
• Optionally, we could let developers configure the animation delay via #3

Is your feature request related to a problem? Please describe.
The CWV values reported by the extension are useful snapshots of the UX, but they don't necessarily have any diagnostic information for developers to understand what could have caused adverse experiences.

Describe the solution you'd like
I'd like to see the extension utilize console logging more to leave an audit trail to assist developers with debugging CWV issues. For example, log the times at which CLS changes and if possible attribute each shift to the culprit element. Or for LCP, log the elements that are considered the largest and the times at which they are painted. For FID, it'd be helpful to know the timestamp of the first input and what was clicked.

The extension can be a first class developer tool for not only understanding how pages are experienced but also debugging how to make them better. Stretch goal: maybe like a VisBug for performance?

Over the last few weeks, we have received a few reports about the extension consuming increased CPU when certain pages are open (in particular Google Meet) - this is generally due to these pages having a high CLS. This has been an issue we previously tried to tackle using badge update throttling. It helped some users, but we're still hearing this is an issue for others. What are our options?

Option 1 ✋🏽

We consider adding an internal disallow list to the extension which skips badging URLs we deem to be sufficiently problematic (e.g meet.google.com). This would leave these tabs with a gray badge, similar to internal Chrome pages. I would only be comfortable doing this in the most egregious of cases.

Option 2 👀

Disable badging for a tab if we detect CLS update frequency is high (N updates in M time window) and looks like it will continue to be high. The benefit of this solution is that it's more general than 1 (...and would help with cases like this where Reddit appears to be the culprit). The other benefit is that you can still do some badging for a tab without disabling it outright.

The downside is that a tab has to get close to behaving badly before we intervene, but we can tweak the time window to reduce the risk here.

@rviscomi @patrickhulce do you have any preferences on the above?

The extension currently provides a local view of your URL's Core Web Vitals metrics but it can also be valuable to get insight into aggregate field data for the URL too (e.g at an origin or URL-level). We will explore adding field data to the extension via CrUX.

Some considerations:

• Initial implementation will be behind a flag until we roll-out
• Only attempt to fetch information if we're not on localhost
• Attempt to match the field metrics UI in current PageSpeed Insights for distributions
• Expose an option for developers to turn off field data (as this will lengthen the drill-down UI)
• Utilize caching so we don't call the REST API too frequently
• Only expose field data in the drill-down, but not the overlay? (I guess given this data will not change during development it's less useful in the overlay?)

@rviscomi any other considerations?

Once you load the extension you normally have pages loaded... thus show up as grey (fine!) and when you click on the badge an empty windows pops up.

Instead: could say something there and even offer "how about reload?" :)

Actually, it's also in the general "grey because results haven't come back yet" case.... so wouldn't want to offer reload while it's loading.

Summary:

• When a developer installs the extension, in addition to the Ambient Badge, we can also render an in-page persistent heads-up display with WebVitals.js RUM data.
• This HUD should maintain a level of opacity (0.7?) to ensure the developer can still see the underlying UI to the page. This is inline with other HUD DX offered in Chrome DevTools for the FPS HUD.
• This HUD should provide a way to optionally close it (e.g an X) in case a developer decides it’s too invasive for their current session.
• We could expose a user-preference in extension settings to toggle on/off the HUD.

Initial mock up: https://glitch.com/edit/#!/metrics-overlay?path=index.html:26:36

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Additional context
Add any other context or screenshots about the feature request here.

Report: https://twitter.com/unix_root/status/1257732387074535425/photo/1

Repro confirmation:

Installed the Chrome extension (Web Vitals .1.1) on my Macbook Pro. (El Capitan v. 10.11.6). On first install, extension was shown with three errors, however it turned out i didn't have the latest version of Chrome. So I updated that and it's now the latest version - 81.0.4044.138 (Official Build) (64-bit) and there's one error in the extension.

Unchecked runtime.lastError: Cannot access contents of url "chrome-search://local-ntp/local-ntp.html". Extension manifest must request permission to access this host.
Context
_generated_background_page.html
Stack Trace
_generated_background_page.html:0 (anonymous function)
Nothing to see here, move along.
Unchecked runtime.lastError: Cannot access a chrome:// URL

Few changes we need to account for including the switch from promises to callbacks GoogleChrome/web-vitals@3004363

I get confused when I see "CLS 0.00" on the red background. It's probably because of my anchoring.... but it takes me a minute to realize "ohhhh that's right.... it's red because in general it didn't pass, not because CLS didn't hit it's threshold".

One idea / option: when red, only cycle through the items that are missed (and often it will just mean it's static on the one error if the other two pass).

• Ambient badge
• Pop-up drill-down
• Opt-in overlay

Totally optional. I think it'd be cool to see the rate of change of a metric like CLS plotted graphically. This wouldn't be the default view but behind some kind of advanced/more button.

@addyosmani wdyt?

Edit: To clarify I'm only referring to the span of time that the tab is active, not a historical view of previous page loads.

For example, let's provide a way to visualize how CLS got to be 0.15. There should be a line at 0.1 indicating where the threshold is and as the page loads and is scrolled, we could see CLS creeping closer to and exceeding the threshold.

Docs: https://developer.chrome.com/extensions/options
Related: #1 (HUD Overlay)

We should expose options UI for users to toggle on/off the HUD overlay. This feature should not be enabled by default as it could be considered a little invasive for every single page-load.

Later, we can also use the options surface for providing more granular control over aspects like... do you want us to fetch field data from the PSI report? (default: true) or enable more power-user features.

Preference on in-popup options vs. dedicated options page (e.g in a new window). I don't have a strong opinion here but have come across more extensions that choose the new window options page approach.

I'm guessing video messes with CLS events or something because while I had a video call the extension was flickering rapidly and Chrome's task manager pointed to the extension process as being maxed out at 100% CPU with fans spinning. Maybe we can throttle the computation somehow?

Rather than keeping this commented out until later in May, let's just put the implem behind a feature-flag. Makes it easier for development.

Searchbox

Missing action checkbox

I was initially confused by what (final) and (not final) meant. At first I thought it was a signal on the metric implementation or something because (not final) only appeared on CLS when I first opened the extension. I quickly realized it was whether the value might change or we're definitely done computing the metric.

I'm not sure who the audience of the extension is, but if they there's opportunity for confusion there I'd like to offer (still computing) along with a loading icon or something to make it super clear? I wasn't able to read the linked docs because web-vitals is a separate private repo it seems, so maybe it explains it more there already.

Repro Steps

• Navigate to https://www.theverge.com/
• Click on the page to trigger FID
• Open the extension to observe the metrics, note their values
• Open DevTools on the page and enable Fast 3G throttling
• Refresh the page and wait for it to load
• Open the extension to observe the metrics, note none of their values have changed and they all read "final", even CLS
• Repeat the refresh as many times as you like without changes.
• Disable Fast 3G throttling
• Refresh the page and wait for it to load
• Open the extension to observe the metrics, note their values change again

Other Notes

• If I switch tabs and go back to the throttled tab, the metric values appear correctly again.
• Sometimes I'll even see an LCP of 0.00 s
  

Related Issues
It'd be great if the URL and timestamp of the page load the metrics were from was listed in the extension, it was hard to tell on refresh if the numbers were actually current or not.

Using the extension for the first time I wasn't sure how to interpret final/not final:

One idea: could each row have a ? that's a link which points at its respective article (web.dev/cls, web.dev/lcp, etc)

LCP should stop updating after user input, but in a long-lived tab I found that it's still periodically updating. For context: https://twitter.com/rick_viscomi/status/1278567773657092097

Should we add a note to LCP that the value is inflated, similar to when the tab was loaded in the background?

I'm also interested to find out how it got this high in the first place and if this is considered a bug.

I know it's a preview, but this will be a significant barrier to adoption for many developers.

Also, once it's on the web store, I'd suggest adding a large, obvious CTA to both the homepage and the readme. Right now, the homepage is lacking a clear CTA to get started with the extension which is the flow that 95% of people will want to take.

Cheers 😄

Describe the bug
The first initial visit to an SPA site it fine, but if you go to a new page handled by an internal router (i.e. the page is hydrated without a reload) the subsequent page views stack up in the metrics, so you have a combined CLS of all page views, and seemingly the LCP & FID of the initial page.

To Reproduce
Go to any SPA that works this way and click around, monitoring the figures.

Expected behavior
It would be great if the route change could be detected and the metrics adjusted accordingly.

Version:

• OS w/ version: Windows 10
• Browser w/ version: Chrome 83

Lighthouse heeft een fout geretourneerd: NO_FCP. Er is iets misgegaan bij het registreren van de tracering tijdens het laden van uw pagina. Voer Lighthouse opnieuw uit. (NO_FCP)

Describe the bug

Clicking on extension popup often shows 'Metrics unavailable while HUD appears to show correct values, See screenshow below

To Reproduce

I haven't been able to fully identify the steps to reproduce. I suspect however that it happens when either all values or the CLS value approach zero or are zero.

Expected behavior
To show the metrics. As I understand, even if the values are low it should still show them?

Version:

• OS w/ version:
  (Xubuntu flavor)
  Distributor ID: Ubuntu
  Description: Ubuntu 20.04.1 LTS
  Release: 20.04
  Codename: focal
• Browser w/ version Chrome 86.0.4240.183 (Official Build)

Additional context, screenshots, screencasts

Due to a number of issues I experienced when importing WebVitals.js into a content script, we currently inline the UMD build in https://github.com/GoogleChrome/web-vitals-extension/blob/master/extension/src/browser_action/vitals.js#L18.

This probably won't scale over time and we should fix it sooner rather than later so we can pull in library updates as needed. As the latest version of the library relies on callbacks vs. promises, we're already a little out of date and would need to update to account for this after this change.

• Check on official policies
• Track actives?
• Track badge-clicks / pop-up opens
• Track overlays enabled

When participating in some meetings not just in meet.google.com the website is freezing and the points in the extension change a lot.
I would suggest avoiding the load in these scenarios or to have a toggle button to not load in some specific sites.

Per web.dev/fid:

FID measures the time from when a user first interacts with your site (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control)

However, when I click on any non-interactive part of the page, like the background, FID appears as finalized in the console log and the drill-down UI. I'd expect it to stay indeterminate until interacting with part of the UI.

This could be a bug in the JS library, the perf API, or just a misunderstanding in the docs.

An error appear after i installed the extension

Describe the bug

It looks like we may have some additional memory leaks sitting around 🚿 Once all tabs that are badged are closed, memory usage from the extension remains in the ~50MBs on my machine.

This continues to grow if left open for a few minutes.

To Reproduce

1. Open four tabs in sequence - web.dev, cnn.com, theverge.com, disney.com
2. Wait for the tabs to fully load
3. Measure extension's memory consumption and CPU utilization using Chrome's Task Manager
4. Close all open tabs except about:extensions
5. Measure extension's memory consumption and CPU utilization using Chrome's Task Manager

This appears to also be present after #68 and #69 cc @patrickhulce as an fyi

This extension is great!
One thing that I am not sure is clear at the moment is that this tells you that the current device passes this current URL ("my homepage is green when I load it on my dev laptop! i'm all good"). Since real user data is so important to Web Vitals, it might make sense to make it more explicit that just because it passes on your dev device does not mean it actually passes for your users.

For example

• include the current URL in the drill down mode (e.g. metrics for example.com/foo/bar...)
• warn that testing on localhost is not representative of a prod environment

Sorry if this has been discussed already, great work all!

CWV defines three buckets of experience: good, needs improvement, and poor. Currently, the extension labels anything not good as poor.

Should the extension account for experiences in the needs improvement bucket?

As first raised by @patrickhulce there are cases where a page with highly dynamic in-viewport content may cause frequent updates to the badge. e.g a page with in-viewport animations (e.g http://mdn.github.io/performance-scenarios/js-worker/index.html - select rAF and animate) will cause a firehose of CLS updates with significant badge flashing.

To address this, we could do a few things:

1. Limit how often broadcastMetricsUpdates is called
2. Limit how often specific metrics in the broadcast can trigger a badge change (LCP and FID are impacted far less by these problems than CLS). We could add some logic here so that we only throttle CLS badge updates.

Of these options, I'm tempted to try 2. first and see if this leads to the above demo working without causing the badge to flicker so much.

Might use https://www.npmjs.com/package/lodash.debounce for this unless there's some other hotness I should be looking at... :)

I am enjoying looking at a scoreboard and peaking at the overall view of things.

One idea would be to have an option to show meta information such as:

• % of runs (final) scores that hit vs. don't
• top 5 / bottom 5 list (not sure the right numbers, if they reset each week etc)

The following error is shown within the extension (Errors) page every time you open a new tab.

The current badge overlay close button will remove the badge from the page, but will not persist the badge closure during your session. This might be surprising to developers (e.g I see my metrics -> close badge -> CLS wasn't final and just updated -> whoops here's the badge again).

Few options....

1. Clicking close will be the same as disabling the overlay for the particular tab (i.e we update your overlay preferences on clicking 'Close' and you have to go back to the Options to re-enable it). I think this would be the simplest option.
2. Clicking close has some session awareness. If you reload the page or come back later, we'll bring back the overlay. I'm currently thinking 1 might be sufficient.

@housseindjirdeh interested in taking this one when you have time?

With the extension installed...

1. Create a number of new tabs (e.g 5)
2. Navigate to a new URL for each tab (e.g cnn.com, web.dev, wikipedia etc)
3. Switch back and forth between the tabs
4. Some of the tabs will display a grey icon (i.e we do not yet know if the page metrics pass the Core Web Vitals thresholds), however, clicking on the badge for the drill-down shows that we do have metrics data with some degree of pass/fail already.

What could be the cause?

• Waiting on metrics to finalize (e.g FID is not yet final) so we are showing grey
• Issues in the chrome extension event lifecycle may be delaying the badge icon from being updated

I got a notification "Web Vitals extension crashed, click this balloon to reload" after switching between a couple tabs quickly.

Here's the error log from chrome://extensions