Summary

When an account has a large volume of URLs, the Web Vitals dashboard breaks. In the console you can find this message:

Executor error during find command :: caused by :: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.

This is obviously the result of an API query that is too broad and which the DB rejects due to the resources needed to fulfill.

We need to re-evaluate the Web Vitals service because when used by larger websites, it requires intense management of data resources and presentation. This is very high priority, because we are serving users a broken experience.

Summary

After setting extra headers on a page, removing it is not possible.

Summary

Free users should not be see a button to cancel their account. Instead there should be messaging to contact us so we can close on our end.

Expected Behavior

Free users should not see a cancel button in their account details.

Actual Behavior

Free users see a cancel button in their account details. When this button is clicked it actually partially works, putting their account in a broken state.

Environment

All environments

Screenshots

Summary

Seeing these errors show up when URLs use custom headers with Authorization: Basic <some token>:

Error: Protocol error (Network.setExtraHTTPHeaders): Invalid header name

Also, when this occurs - users do not see the issue in the UI.

Items to Fix

1. Messaging: Users should see messaging from any Lighthouse failures.
2. The value of this header is in a string / correct format. We need to get to the bottom of why the error is thrown and fix it.

Summary

Users who haven't confirmed email are unable to resend confirmation.

Actual Behavior

Messaging is outdated.

Expected Behavior

Support resending confirmation email.

Summary

Manually triggered audits were previously expedited during times that a queue of automated audits were underway. This functionality seems to be working incorrectly.

Actual

When a user triggers an audit (manually or on page creation) the user could end up waiting for up to 45 minutes before seeing results and the messaging is inaccurate (screenshot below).

Expected

Manually triggered audits should be expedited.

Screenshots

Summary

PROTOCOL_TIMEOUT errors have been occurring more frequently. These errors are known as part of the Lighthouse project. On our stack, they only occur on a small handful of domains, about 10 out of 1,000 URLs... however, this is a poor experience for our affected users and not very acceptable as a service provider. Core contributors of Lighthouse have acknowledged the issue (GoogleChrome/lighthouse#6512), but the traction to provide a solution is very low. According to them the issues reside in Chromium, not Lighthouse and they've explained that the Chrome team is looking into the threads from the linked issue.

We've attempted to remedy the issue with different sized AWS instances and we've most recently migrated to powerful instances on Digital Ocean. We've also tried various flavors of Docker containers: Alpine, Ubuntu, Debian. Some URLs consistently fail when using running with Lighthouse directly (programmatically).

Related Issues

GoogleChrome/lighthouse#6512

Summary

We should show mobile specific data when the Lighthouse audit is for mobile and desktop respectively.

Summary

We allow URL dashboards to be publicly for sharing purposes since data is insensitive. Anyone can run a Lighthouse audit on any publicly accessible page. However, users may not want this data to be publicly accessible and in fact certain fields could be sensitive.

Actual Behavior

URL dashboard pages are publicly accessible.

Expected Behavior

We should restrict Lighthouse dashboard pages altogether for logged in users only.

It should also be noted that when an attempt is made to edit data, the form actually submits and displays a success message even though the PUT request does not fulfill the intention - this request should respond with a 401 status code.

Summary

1. From the dashboard, I attempted to add a Slack connection.
2. I logged into my Slack account
3. I was able to choose a channel from my Slack account
4. When I clicked the "Allow" button on slack.com I got the following error message (in Chrome):

Attackers might be trying to steal your information from www.automated-lighthouse-check.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID

This server could not prove that it is www.automated-lighthouse-check.com; its security certificate expired 3 days ago. This may be caused by a misconfiguration or an attacker intercepting your connection. Your computer's clock is currently set to Monday, December 21, 2020. Does that look right? If not, you should correct your system's clock and then refresh this page.

Related Issues

Add any related issues here.

Actual Behavior

"Your connection is not private" message from Chrome

Expected Behavior

I was expecting to connect to my Slack account, and be able to send notifications to a Slack channel.

Environment

Any details about your environment is greatly appreciated. Example below.

• OS: macOS v10.14.6
• Browser: Chrome v84.0.4147.105

Screenshots

Summary

Document this somewhere highly visible.

Summary

This could be missing configuration in the Data Studio template, otherwise if its not available, we'll need to workaround by updating the connector code.

Actual Behavior

On hover state, the latest score for the day is displayed.

Expected Behavior

On hover state, the average score for the day is displayed.

Summary

When Lighthouse audits fail on www.foo.software, the UI doesn't show an error message or anything to reflect this. Once in a while Lighthouse times out with a PROTOCOL_TIMEOUT error for complicated or slow pages (see issue linked below). Unfortunately, certain URLs time out more than others.

Related Issues

• GoogleChrome/lighthouse#6512

Actual Behavior

When manually triggering an audit on a dashboard page similar to this one or via the public API, the UI shows a loading state and message. Eventually, if the audit fails the loading state disappears and nothing else is shown (typically from a PROTOCOL_TIMEOUT error). Audits that run automatically also don't show on the dashboard when they've failed.

Expected Behavior

When Lighthouse audits fail, we should show some type of failure message.

Summary

Although we don't necessarily need to document the exact time audits occur, we should document something about it.