Performance & Uptime

A slow site is a broken site. Users leave before the page loads. Google ranks you lower. Conversions drop. And when your site goes down entirely, you lose everything until it comes back.

Performance and uptime monitoring give you visibility into how your site performs for real users — not just whether it works on your machine.

This guide covers the full scope of performance monitoring: what to measure, how to interpret the data, and how to fix the problems you find.

Contents

• Why performance matters
• Core Web Vitals
• Uptime monitoring
• Real user vs synthetic monitoring
• Performance and conversions
• Common performance problems
• Building a monitoring stack
• Frequently asked questions

Why performance matters

Performance affects everything:

A page that loads in 1 second feels instant. A page that loads in 3 seconds feels slow. A page that loads in 5 seconds feels broken.

The challenge is that performance varies. Your site might load fast on your fiber connection in your office, while loading slowly on a mobile phone in a rural area. Performance monitoring captures what real users actually experience.

Core Web Vitals

Google's Core Web Vitals are the most important performance metrics to track. They measure three specific aspects of user experience:

These metrics are ranking factors in Google Search. Sites with good Core Web Vitals get a small ranking boost over sites with poor vitals in competitive searches.

More importantly, they measure real problems that frustrate users: slow loading, unresponsive buttons, and content that jumps around.

For a complete breakdown of each metric and how to improve them, see the Core Web Vitals guide.

Uptime monitoring

Uptime monitoring answers the simplest question: is your site up?

How uptime monitoring works

A monitoring service sends requests to your site at regular intervals — every minute, every 5 minutes, or longer. If the request fails (timeout, error response, wrong content), you get alerted.

What to monitor

At minimum, monitor:

• Your homepage
• Critical pages (checkout, login, pricing)
• Your API endpoints if you have them
• Any external dependencies that affect functionality

Alert fatigue

The goal is to be notified of real problems, not every brief hiccup. Good uptime monitoring includes:

• Retry before alert — Check fails, wait 30 seconds, check again before alerting
• Multiple locations — Confirm the problem isn't regional before alerting
• Escalation — Email first, then SMS if not acknowledged

Real user vs synthetic monitoring

There are two fundamentally different approaches to performance monitoring.

Synthetic monitoring

Automated tests run from controlled locations on controlled devices. Think of it as a lab test.

Pros:

• Consistent, comparable over time
• Can test from multiple geographic locations
• Works before you have traffic

Cons:

• Doesn't reflect real user diversity
• May miss issues only visible on real devices
• Tells you what could happen, not what does happen

Real User Monitoring (RUM)

JavaScript on your pages captures performance metrics from actual user sessions.

Pros:

• Reflects actual user experience
• Captures device/browser diversity
• Shows geographic variation

Cons:

• Requires traffic to generate data
• Noisier data (real users have varied conditions)
• Adds a small amount of overhead

Which to use

Use both if you can. Synthetic monitoring gives you a consistent baseline and catches problems immediately. RUM shows you what real users actually experience.

If you can only use one, RUM is more valuable — it tells you what's actually happening, not what might happen in theory.

Performance and conversions

Performance problems cost conversions. This is measurable.

Segment your conversion data by performance metrics:

If sessions with slow LCP convert at one-quarter the rate of fast sessions, improving LCP directly increases revenue.

This connection between performance and conversions is why monitoring tools should track both. When you see performance decline, you want to know immediately whether it's affecting conversions — not find out weeks later.

Common performance problems

Slow server response

The server takes too long to start sending the response. Common causes:

• Overloaded shared hosting
• Unoptimized database queries
• No caching at the server level
• Server geographically far from users

Fix: Upgrade hosting, add caching, optimize slow queries, use a CDN.

Large images

Uncompressed images are the most common cause of slow pages. A single 3MB hero image can make a page feel slow on any connection.

Fix: Compress images, use modern formats (WebP, AVIF), serve responsive sizes, lazy load below-fold images.

Render-blocking resources

CSS and JavaScript files in the <head> block rendering until they load. Too many external stylesheets and scripts create bottlenecks.

Fix: Defer non-critical JavaScript, inline critical CSS, reduce third-party scripts.

Too many third-party scripts

Each analytics tool, chat widget, ad network, and marketing pixel adds load time and competes for JavaScript execution. Third-party scripts are often the biggest INP offenders.

Fix: Audit scripts, remove unused ones, delay non-essential scripts until after page load.

No caching

Every page request rebuilds from scratch instead of serving cached content. This wastes server resources and slows response time.

Fix: Implement page caching, use CDN edge caching, set appropriate cache headers for static assets.

Building a monitoring stack

A complete performance monitoring setup includes:

For most websites, a single tool that combines uptime and RUM is sufficient. You don't need enterprise observability stacks.

Connect your performance monitoring to error monitoring. Performance problems often cause or accompany errors. Slow pages lead to timeouts. Timeouts lead to errors. Errors lead to rage clicks. The data is more valuable when connected.

Frequently asked questions

How often should uptime checks run?

Every 1-5 minutes for critical pages. More frequent catches problems faster but costs more. Less frequent is fine for non-critical pages.

What's a good page load time target?

Under 3 seconds for the main content to be usable. Under 2 seconds is ideal. Google's LCP threshold is 2.5 seconds for "good."

Does performance monitoring slow down my site?

RUM adds a small JavaScript payload — typically 5-15KB compressed. The impact on load time is minimal (a few milliseconds). The value of the data far outweighs this cost.

Should I monitor from multiple locations?

Yes, if your users are geographically distributed. A site can be fast in New York and slow in Singapore. Multi-location monitoring catches regional problems.

How do I know if a performance problem is affecting conversions?

Correlate the data. Segment conversion rates by performance metrics. If slow sessions convert at lower rates, performance is affecting conversions. Tools that combine performance and conversion tracking make this easy.

Sub-pillars

Core Web Vitals

Google's three key metrics for user experience: LCP, INP, and CLS. What they mean and how to improve them.

Uptime Monitoring

Know when your site goes down before users do. Set up monitoring that catches outages and tracks availability.

Next steps

If you're new to performance monitoring:

• Set up uptime monitoring for your critical pages
• Run a Lighthouse test to see your current Core Web Vitals
• Install RUM to start collecting real user data

If you're already monitoring:

• Deep dive into Core Web Vitals optimization
• Connect performance data to conversion tracking
• Review error monitoring alongside performance for full site health