# Performance & Reliability

The Web Analytics **Performance & Reliability** page shows if a slow or broken site makes visitors leave. Fix the slow pages that also lose the most people, and the pages where visits hit a dead end.

## Before you start [#before-you-start]

- Install the Web Analytics script. See [Analytics script](/connect/analytics-script). Without the script, the page shows **Install Web Analytics to see whether a slow site costs you visitors**.
- Verify the domain. See [Verify ownership](/getting-started/domain-setup/verify-ownership).
- For the speed parts, install the RUM script. See [RUM script](/connect/rum-script).
- For downtime and the **Reliability** card, set up [Uptime Monitoring](/uptime-monitoring/overview).
- In the sidebar, select **Web Analytics** > **Performance & Reliability**.
- Select the dates in the filter dock. The default is **Last 28 days**. This page has no comparison, and it counts whole days in UTC.

VitalSentinel calculates these reports in advance, so the page has no refresh button. If you select other dates or add filters, the reports calculate when you open the page.

### Without RUM Monitoring [#without-rum-monitoring]

If RUM Monitoring is not installed, the page shows **See whether slow pages lose you visitors**. RUM Monitoring measures how fast each page feels to real visitors. Owners and admins can click **Install the RUM script**. The **Reliability** card and the dead ends still show.

### Core Web Vitals [#core-web-vitals]

Core Web Vitals are three measures from Google of how fast a page feels:

- **LCP** (Largest Contentful Paint): how long until the main content finishes loading. Good is 2.5 seconds or less.
- **INP** (Interaction to Next Paint): how long the page takes to respond to a click or tap. Good is 200 milliseconds or less.
- **CLS** (Cumulative Layout Shift): how much the page jumps around while it loads. Good is 0.1 or less.

## Speed verdict [#speed-verdict]

The Web Analytics **Performance & Reliability** page starts with one sentence about speed and bounce rate:

| Sentence | Meaning |
|---|---|
| **On slower landing pages, 12 more visitors in 100 leave after one page** (example) | Slow pages lose 5 or more visitors in 100 more than fast pages |
| **Page speed is not costing you visitors** | Slow and fast pages lose about the same share |
| **Slower pages do not lose visitors here** | Slow pages lose fewer visitors than fast pages |
| **Not enough pages to compare fast and slow landing pages yet** | Too few fast or slow landing pages with visits |

The **?** shows **Landing pages compared**. If one page brings most visits of a speed group, VitalSentinel leaves that group out, and the **?** says so, for example **Slowest group left out**.

If no page has both RUM data and visits, and the period has no outage and no dead end, the page shows **No data for this view**. Select a wider date range.

If Web Analytics found problems, a banner such as **Performance & Reliability: 2 open issues** shows. It links to [Site Health](/site-health/overview).

## Speed and bounce tiles [#speed-and-bounce-tiles]

The Web Analytics **Performance & Reliability** page shows four tiles:

| Tile | What it shows |
|---|---|
| **Bounce on fast pages** | The share of visits that ended after one page, on pages Google grades as fast |
| **Bounce on pages that need work** | The same share on pages Google grades as needing improvement |
| **Bounce on poor pages** | The same share on pages Google grades as poor |
| **Downtime** | Minutes the site was down in this period, from your uptime checks |

A big gap between fast and poor pages means that speed costs you visitors. A group with no visits shows **No visits in this group**.

**Downtime** shows **No outages** when the site was up. Without Uptime Monitoring, it shows **Connect Uptime Monitoring to measure downtime**.

### Filters on this page [#filters-on-this-page]

Filters narrow the visits that the page counts. The speed of a page stays measured on all its visitors. Only the **Device** filter narrows the speed. Downtime is always for the whole site.

## What holds pages back [#what-holds-pages-back]

The Web Analytics card **What holds pages back** has one block for each Core Web Vital: **Slow to load** (LCP), **Slow to respond** (INP) and **Jumps around** (CLS). Each block shows:

- A status: **Good**, **Needs work** or **Poor**.
- How many landing pages are over the limit, and how many visits start on them.
- A bar that shows where the busiest failing page falls on the scale. The value is for a typical visit: 3 in 4 visits were this good or better.

If no page is over the limit, the block says so. Start with the measure that has the most slow pages. Click the name of the measure to open it in [RUM Monitoring](/rum-monitoring/overview).

## Landing pages by Core Web Vitals [#landing-pages-by-core-web-vitals]

The Web Analytics card **Landing pages by Core Web Vitals** lists each landing page, slowest first. It has two tabs.

**Speed** shows **Page**, **Grade**, **LCP**, **INP**, **CLS**, **Entries** and **Bounce rate**. **Grade** is **Good**, **Needs work**, **Poor** or **No data**.

**Engagement** shows **Active time**, **Scroll depth**, **Purchases** and **Conv. rate** for each page. **Entries** counts the visits that entered the site on this page.

Fix the slowest pages that get the most visits. If no page has both speed data and visits, the card shows **No pages have both real-user speed data and visits in this period**.

At the bottom of the page, the card **Speed groups in detail** shows **Speed grade**, **Visits**, **Bounce rate**, **Active time**, **Scroll depth** and, for shops, **Conv. rate** and **Revenue per visit**.

## Reliability [#reliability]

The Web Analytics card **Reliability** lists each outage in the period and the visits it most likely cost. It needs Uptime Monitoring. Without it, the card shows **See whether outages cost you visitors** and **Set up Uptime Monitoring**. If the period had no outage, the card does not show.

| Column | What it shows |
|---|---|
| **Started** | The day the site went down |
| **Down for** | How long the site was down, in minutes |
| **Failed checks** | How many uptime checks failed during the outage |
| **Visits lost** | An estimate: the visits you would normally expect at those hours |

The tiles **Visits lost to outages** show the total **Visits lost** and **Not priced** (outages with no earlier traffic to compare with). VitalSentinel compares each outage with the same weekday and hour over the four weeks before. Click **Open Uptime Monitoring** to see why the site was down.

## Pages people land on that do not work [#pages-people-land-on-that-do-not-work]

The Web Analytics card **Pages people land on that do not work** lists the dead ends: landing pages that are not found, fail, redirect or refuse people. The tiles **Dead ends at a glance** show:

- **Visits that hit a dead end**, on how many pages.
- **Share of all landings**: dead-end visits out of all visits.
- **Orders at stake**: an estimate of the orders these visits could bring.
- **Pages to fix**.

### Dead end tabs and columns [#dead-end-tabs-and-columns]

The table has the tabs **Not found**, **Server errors**, **Redirects**, **Blocked** and **Not checked yet**. The columns include:

- **Page**, **Answer** (what the page answers) and **Visits**.
- **Top sender**: the campaign, site, Google or AI assistant that sent the most visits.
- **Still in Google**: how often Google showed the page, and if a sitemap still lists it. This needs [Google Search Console](/connect/search-console).
- **Last worked**: the last day Site Health Monitoring or [Page Monitoring](/page-monitoring/overview) saw the page work.
- **Redirect to**: the closest page that works, by name. **Goes to** shows where a redirect leads now.

The status comes from the most recent check by Site Health Monitoring or Page Monitoring.

### Who sends them [#who-sends-them]

The card **Who sends them** lists who sends visitors to dead pages. It has the tabs **Campaigns**, **Sites**, **Google** and **AI assistants**. Ask the sender to update the link, or add a redirect.

### Fix dead ends [#fix-dead-ends]

At the bottom of the page, the card **Fix dead ends** creates redirect rules from the suggested pages. Select a format from the menu: **Apache (.htaccess)**, **nginx** or **CSV (from, to)**. Then copy the rules to your server.

Some addresses have characters that cannot go into a redirect rule safely. Some pages have no suggested page yet. The card says so for these pages.

## Troubleshooting [#troubleshooting]

### Why does Performance & Reliability show "See whether slow pages lose you visitors"? [#why-does-performance--reliability-show-see-whether-slow-pages-lose-you-visitors]

RUM Monitoring is not installed. The speed tiles and cards need it. Install the RUM script. See [RUM script](/connect/rum-script).

### Why does the page say "No data for this view"? [#why-does-the-page-say-no-data-for-this-view]

No page has both RUM data and Web Analytics visits in the period. Select a wider date range. Check that both scripts are on the same pages.

### Why does Downtime say "Connect Uptime Monitoring to measure downtime"? [#why-does-downtime-say-connect-uptime-monitoring-to-measure-downtime]

Uptime Monitoring is not set up for this domain. Set it up in [Uptime Monitoring](/uptime-monitoring/overview).

### Why does the page say "Not enough pages to compare fast and slow landing pages yet"? [#why-does-the-page-say-not-enough-pages-to-compare-fast-and-slow-landing-pages-yet]

There are not enough landing pages with visits in the fast group or in the slower groups. The tiles still show the figures. Select a wider date range.

## Related [#related]

- [RUM Monitoring](/rum-monitoring/overview) - Core Web Vitals from real visitors
- [Uptime Monitoring](/uptime-monitoring/overview) - outages and response times
- [Performance & engagement](/google-search-console/performance-and-engagement) - if slow pages get fewer Google clicks
- [Engagement](/web-analytics/engagement) - where readers leave without engaging
- [Site Health](/site-health/overview) - dead-end and speed issues