Speed Insights Overview

Vercel Speed Insights provides you with a detailed view of your website's performance metrics, facilitating informed decisions for its optimization. For granular visitor data, turn to our Web Analytics.

By enabling Speed Insights, you gain access to the Speed Insights dashboard, which offers in-depth information about scores and individual metrics without the need for code modifications or leaving the dashboard. It's the key to analyzing your site's performance parameters without the hassle of introducing new scripts or headers.

Once enabled, you'll see an interface where gathered data can be sorted and inspected based on a variety of parameters:

• Device type, including Mobile, Tablet, and Desktop
• Percentile of data representing a certain fraction of users; options include P75, P90, P95, P99
• Reporting window for data points, ranging from the last day up to the last 28 days (duration varies depending on the account type)

To get started with Speed Insights, use the Quickstart

Pricing for Speed Insights is based on the number of data points used. You can learn more about costs in the Pricing documentation.

While many performance measurement tools, like Lighthouse, estimate user experience based on lab simulations, Vercel's Real Experience Score (RES) uses real data points collected from your users' devices.

As a result, RES offers an authentic evaluation of your users' actual experiences with your application. This real-time data allows you to gauge the true performance of your application, providing a continuous stream of insights that are invaluable for tracking changes over time.

By integrating these insights into your development workflow through our dashboard, you can easily correlate shifts in performance with new deployments. This real-time feedback can help you fine-tune your application, ensuring optimal user experience.

An example of a Real Experience Score over time.

The Real Experience Score (RES) displayed in the Speed Insights tab is derived from actual data points collected from your visitors' devices. As such, it can only offer insight into your app's performance post-deployment. While it's critical to gather these real-world data points, they only reflect user experiences after the fact, limiting their predictive power.

In contrast, the Virtual Experience Score (VES) is a predictive performance metric that allows you to anticipate the impact of changes on your app's performance, ensuring there's no regression in user experience. This metric is provided by integrations like Checkly that employ Deployment Checks.

Setting up an integration that supports performance checks enables these checks to run for each deployment. These checks assess whether the user experience is likely to improve or deteriorate with the proposed changes, helping guide your decision-making process.

Like RES, the VES draws from four separate Speed Insights, albeit with some variations:

• In place of the First Input Delay (FID) Core Web Vital, the Virtual Experience Score utilizes Total Blocking Time (TBT)
• The specific device type used for checks depends on the Integration you've set up. For example, Checkly only uses "Desktop" for determining scores

The Core Web Vitals, as defined by Google and the Web Performance Working Group, are key metrics that assess your web application's loading speed, responsiveness, and visual stability.

First Contentful Paint (FCP) is a performance metric that measures the time from the moment the page starts loading to the moment the first piece of content from the Document Object Model (DOM) is rendered on the screen. This could be any content from the webpage such as an image, a block of text, or a canvas render. The FCP is important because it indicates when the user first sees something useful on the screen, providing an insight into your webpage's loading speed.

Lower FCP times are better, with an FCP time of under 1 second being considered good.

Largest Contentful Paint (LCP) is a performance metric that measures the time from when the page starts loading to when the largest content element in the viewable screen is fully displayed. This could be an image, a video, or a block of text. LCP is important as it gives a measure of when the main content of the page is visible to the user.

A good LCP time is considered to be 2.5 seconds or less.

Cumulative Layout Shift (CLS) is a performance metric that quantifies how often users experience unexpected layout shifts—a low CLS helps ensure that the page is stable as it loads. A layout shift occurs any time a visible element changes its position from one rendered frame to the next.

The score is a product of two measures:

• The impact fraction - the area of the viewport impacted by the shift
• The distance fraction - the distance the elements have moved

A good CLS score is considered to be 0.1 or less.

First Input Delay (FID) measures the time from when a user first interacts with your site (by selecting a link for example) to the time when the browser is able to respond to that interaction. This metric is important on pages where the user needs to do something, because it captures some of the delay that users feel when trying to interact with the page.

A good FID score is 100 milliseconds or less.

Interaction to Next Paint (INP) is a metric that measures the time from when a user interacts with your site to the time the browser renders the next frame in response to that interaction.

This metric is used to gauge the responsiveness of a page to user interactions. The quicker the page responds to user input, the better the INP.

Lower INP times are better, but a specific target value for INP is not clearly defined yet, as it's an experimental metric.

As stated by Google, simulating an environment to measure Web Vitals necessitates a different approach since no real user request is involved.

Total Blocking Time (TBT) quantifies how non-interactive a page is. It measures the total time between the First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent user input. Long tasks (over 50 ms) block the main thread, preventing the user from interacting with the page. The sum of the time portions exceeding 50 ms constitutes the TBT.

Lower TBT times are better, with a good TBT time being considered as under 300 milliseconds.

Vercel calculates performance scores using real-world data obtained from the HTTP Archive. This process involves assigning each collected metric (e.g., First Contentful Paint (FCP)) a score ranging from 0 to 100. The score is determined based on where the raw metric value falls within a log-normal distribution derived from actual website performance data.

For instance, if HTTP Archive data shows that the top-performing sites render the Largest Contentful Paint (LCP) in approximately 1,220ms, this value is mapped to a score of 99. Vercel then uses this correlation, along with your project's specific LCP metric value, to compute your LCP score.

The Real Experience Score is a weighted average of all individual metric scores. Vercel has assigned each metric a specific weighting, which best represents user's perceived performance on mobile and desktop devices.

In the Virtual Experience Score, Total Blocking Time (TBT) replaces FID for desktop devices:

This approach allows for a more accurate assessment of your application's performance, based on the actual experiences of your users on different devices.

In the context of Vercel's Speed Insights, a data point is a single unit of information that represents a measurement of a specific Web Vital metric during a user's visit to your website.

Data points are collected on hard navigations, which in the case of Next.js apps, are only the first-page view in a session. During a user's visit, data points are gathered during the initial page load, user interaction, and upon leaving the page.

As of now, up to 6 data points can be potentially tracked per visit:

• On page load: Time to First Byte (TTFB) and First Contentful Paint (FCP)
• On interaction: First Input Delay (FID) and Largest Contentful Paint (LCP)
• On leave: Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), and, if not already sent, Largest Contentful Paint (LCP).

The collection of metrics may vary depending on how users interact with or exit the page. On average, you can expect to collect between 3 and 6 metrics per visit.

These data points provide insights into various performance aspects of your website, such as the time it takes to display the first content (FCP) and the delay between user input and response (FID). By analyzing these data points, you can gain valuable information to optimize and enhance the performance of your website.

The percentile dropdown in the Vercel dashboard allows you to refine your data representation by filtering data points based on user experience. By default, it's set to P75, which offers a balanced overview of the majority of user experiences.

The chosen percentile corresponds to the proportion of users who experience a load time faster than a specific value. Here's how each percentile is defined:

• P75: Represents the experience of the fastest 75% of your users, excluding the slowest 25%.
• P90: Represents the experience of the fastest 90% of your users, excluding the slowest 10%.
• P95: Represents the experience of the fastest 95% of your users, excluding the slowest 5%.
• P99: Represents the experience of the fastest 99% of your users, excluding the slowest 1%.

For instance, a P75 score of 1 second for First Contentful Paint (FCP) means that 75% of your users experience an FCP faster than 1 second. Similarly, a P99 score of 8 seconds means 99% of your users experience an FCP faster than 8 seconds.

Performance metrics, including the Real Experience Score, the Virtual Experience Score, and the individual Core Web Vitals (along with Other Web Vitals) are color-coded as follows:

• 0 to 49 (red): Poor
• 50 to 89 (orange): Needs Improvement
• 90 to 100 (green): Good

Strive to achieve 'Good' scores (90 to 100) for the Real and Virtual Experience Scores to ensure an optimal user experience. However, keep in mind that reaching a score of 100 is extremely challenging due to diminishing returns — the effort required to improve your score grows exponentially the closer you get to 100. Thus, a jump from 99 to 100 demands a much larger metric improvement compared to moving from 90 to 94.

Higher Real Experience and Virtual Experience Scores generally translate to superior end-user experiences, making it worthwhile to strive for improved Web Vital Scores.

Performance scores are color-coded to reflect user experience levels: 'Poor' (red), 'Needs Improvement' (orange), and 'Good' (green). Improvements within the same color range (like moving from a score of 50 to 80, both in the 'Needs Improvement' category) enhance user experience but don't significantly impact search engine rankings.

If you aim to boost your site's search ranking, aim to move your scores into a higher color-coded category, for instance, from 'Needs Improvement' (orange) to 'Good' (green). This change reflects substantial improvements in performance and is more likely to be rewarded with higher search engine rankings.

The Speed Insights view offers a comprehensive list of all Page Names and URLs that your application users visit. Here, 'Page Names' refers to the actual pages you've built, while 'URLs' denote the paths requested by the visitor.

This information is sortable based on three parameters: Data Points, Real Experience Score, and Page Name. It allows for a detailed understanding of the performance of individual pages or paths within your application.

In order for a Page or URL to be listed on the Speed Insights page, a minimum of 10 data points within your selected time range is required. An important thing to remember is that Speed Insights only registers and reports fresh page loads; client-side page transitions do not contribute to these insights.

Speed Insights per page and url of your app.

The Speed Insights feature collects data points for every visitor to your application by sending requests directly from the visitor's browser to Vercel's servers. This is where the data is processed and stored.

If you have a Content Security Policy configured in your application, it's crucial that you permit the domain vitals.vercel-insights.com for outgoing requests using the connect-src directive. This is because the client-side bundle reports Speed Insights through network requests to this domain.

By allowing vitals.vercel-insights.com in your Content Security Policy, you ensure uninterrupted data collection and processing for your application's Speed Insights.