Use Google Lighthouse to evaluate website performance, accessibility, and SEO, then action those insights to improve your overall user experience.

API and Data Access

After a brief loading period, Google Lighthouse will be enabled for the Client. No login or signup is required to use Google Lighthouse.

Upon activation, we'll automatically scan the Client's URL. You can re-scan this URL page anytime via the "Perform Audit" button on the Google Lighthouse dashboard.

When an audit fails to initialize, Google Lighthouse disconnects from AgencyAnalytics. This is caused by Google Lighthouse itself, not AgencyAnalytics.

Specifically, Lighthouse has a 15-second timeout: if the page being audited doesn't return any content within that window, the audit fails. Common causes are an unresponsive server, a firewall blocking Lighthouse's access, or an invalid SSL certificate on the client's URL.

To verify whether the issue is with the site itself, run a test at https://pagespeed.web.dev/. If the same error appears there, the issue is with the website's server or configuration and will need to be resolved on the client's end before Lighthouse can complete a scan.

Google Lighthouse checks the URL provided within your client's settings section.

This is because browsing throttling and external factors, such as routers, CPU issues and open tabs, can impact the overall audit score.

Below is a table listing several common sources of metric variability, their typical impact on results, and the likelihood of their occurrence in different environments, with descriptions of each source.

Page Nondeterminism - Pages can contain nondeterministic logic that changes how a user experiences a page, i.e., an A/B test that changes the layout and assets loaded or a different ad experience based on campaign progress. This is an intentional and irremovable source of variance. If the page changes in a way that degrades performance, Lighthouse should be able to detect it. The only mitigation here is for the site owner to ensure that the exact same version of the page is tested across different runs.

Local Network Variability - Local networks exhibit inherent variability due to packet loss, variable traffic prioritization, and last-mile network congestion. Users with cheap routers and many devices sharing limited bandwidth are usually the most susceptible to this. Applied throttling partially mitigates these effects by enforcing a minimum request latency and a maximum throughput, which masks underlying retries. Simulated throttling mitigates these effects by replaying network activity.

Tier-1 Network Variability - Network interconnects are generally very stable and have minimal impact, but cross-geo requests, i.e., measuring performance of a Chinese site from the US, can start to experience high latency due to tier-1 network hops. Applied throttling partially masks these effects with network throttling. Simulated throttling mitigates these effects by replaying network activity.

Web Server Variability - Web servers have variable load and do not always respond with the same delay. Lower-traffic sites with shared hosting infrastructure are typically more susceptible to this. Applied throttling partially masks these effects by applying a minimum request latency in its network throttling. Simulated throttling is susceptible to this effect, but the overall impact is usually low when compared to other network variability.

Client Hardware Variability - The hardware on which the web page loads can significantly impact performance. Applied throttling cannot do much to mitigate this issue. Simulated throttling partially mitigates this issue by capping the theoretical execution time of CPU tasks during simulation.

Client Resource Contention - Other applications running on the same machine while Lighthouse is running can cause contention for CPU, memory, and network resources. Malware, browser extensions, and anti-virus software have particularly strong impacts on web performance. Multi-tenant server environments (such as Travis, AWS, etc) can also suffer from these issues. Running multiple instances of Lighthouse at once also typically distorts results due to this problem. Applied throttling is susceptible to this issue. Simulated throttling partially mitigates this issue by replaying network activity and capping CPU execution.

Browser Nondeterminism - Browsers have inherent variability in their execution of tasks that impacts the way webpages are loaded. This is unavoidable for applied throttling, as at the end of the day, they are simply reporting whatever was observed by the browser. Simulated throttling is able to partially mitigate this effect by simulating execution on its own, only reusing task execution times from the browser in its estimate.

Here are strategies to deal with variance:

If you have any questions, please get in touch with our friendly support team by following these instructions! We're available 24/5 to help 😄