# Understanding Your Metrics

Real User Monitoring collects a comprehensive set of performance metrics from your actual visitors. This guide explains each metric, what it means, and how to improve it.

***

### Core Web Vitals

These are Google's official metrics for measuring user experience and are used as ranking factors for search results.

#### Largest Contentful Paint (LCP)

**What it measures**: The time when the largest visible content element (image, video, or text block) becomes visible in the viewport.

**Why it matters**: LCP represents perceived loading speed. Users consider a page "loaded" when the main content is visible.

**Thresholds**:

* 🟢 **Good**: ≤ 2.5 seconds
* 🟡 **Needs Improvement**: 2.5 - 4.0 seconds
* 🔴 **Poor**: > 4.0 seconds

**Common causes of poor LCP**:

* Large, unoptimized images
* Slow server response times
* Render-blocking JavaScript and CSS
* Slow resource load times

**How to improve**:

* Optimize and compress images
* Use smoxy's image optimization features
* Enable browser caching
* Use a CDN (smoxy does this automatically)
* Implement lazy loading for below-the-fold images
* Minimize server response time (TTFB)

***

#### Interaction to Next Paint (INP)

**What it measures**: The responsiveness of a page to user interactions - how quickly the page responds to clicks, taps, and keyboard inputs.

**Why it matters**: INP measures how quickly users can interact with your page. High INP means users experience delays when clicking buttons or links, leading to frustration.

**Thresholds**:

* 🟢 **Good**: ≤ 200 milliseconds
* 🟡 **Needs Improvement**: 200 - 500 milliseconds
* 🔴 **Poor**: > 500 milliseconds

**Common causes of poor INP**:

* Heavy JavaScript execution blocking the main thread
* Large JavaScript bundles
* Long-running event handlers
* Unoptimized third-party scripts

**How to improve**:

* Break up long JavaScript tasks
* Use web workers for heavy computations
* Minimize third-party scripts
* Optimize event handlers
* Enable JavaScript minification in smoxy
* Use code splitting to reduce bundle sizes

***

#### Cumulative Layout Shift (CLS)

**What it measures**: Visual stability - how much content shifts around unexpectedly while the page loads.

**Why it matters**: Unexpected layout shifts cause users to accidentally click wrong elements or lose their reading position, creating a frustrating experience.

**Thresholds**:

* 🟢 **Good**: ≤ 0.1
* 🟡 **Needs Improvement**: 0.1 - 0.25
* 🔴 **Poor**: > 0.25

**Common causes of poor CLS**:

* Images without dimensions (width/height attributes)
* Ads, embeds, or iframes without reserved space
* Web fonts causing text to reflow (FOIT/FOUT)
* Dynamically injected content
* Animations that trigger layout changes

**How to improve**:

* Always include `width` and `height` attributes on images and videos
* Reserve space for ads and embeds with CSS
* Use `font-display: optional` or `font-display: swap` for web fonts
* Avoid inserting content above existing content
* Use CSS transforms for animations instead of properties that trigger layout

***

### Page Timing Metrics

#### Time to First Byte (TTFB)

**What it measures**: The time from the browser making a request to receiving the first byte of the response from the server.

**Why it matters**: TTFB represents server processing time and network latency. It's the foundation for all other performance metrics.

**Thresholds**:

* 🟢 **Good**: < 200 milliseconds
* 🟡 **Acceptable**: 200 - 500 milliseconds
* 🔴 **Poor**: > 500 milliseconds

**How to improve**:

* Optimize server-side code and database queries
* Use server-side caching
* Enable HTTP/2 or HTTP/3
* Use a CDN (smoxy provides this)
* Optimize origin server performance
* Reduce server-side processing time

***

#### First Contentful Paint (FCP)

**What it measures**: The time when the first piece of content (text, image, SVG, or canvas) is rendered on the screen.

**Why it matters**: FCP provides feedback to users that the page is loading, reducing perceived load time.

**Thresholds**:

* 🟢 **Good**: < 1.8 seconds
* 🟡 **Needs Improvement**: 1.8 - 3.0 seconds
* 🔴 **Poor**: > 3.0 seconds

**How to improve**:

* Reduce render-blocking resources
* Inline critical CSS
* Preload key resources
* Minimize server response time
* Enable text compression (smoxy does this automatically)

***

#### Total Blocking Time (TBT)

**What it measures**: The total time during page load when the main thread was blocked long enough to prevent input responsiveness.

**Why it matters**: High TBT means the page appears loaded but is unresponsive to user input.

**Thresholds**:

* 🟢 **Good**: < 200 milliseconds
* 🟡 **Needs Improvement**: 200 - 600 milliseconds
* 🔴 **Poor**: > 600 milliseconds

**How to improve**:

* Reduce JavaScript execution time
* Split long tasks into smaller ones
* Remove unused JavaScript
* Minimize third-party code
* Use code splitting and lazy loading

***

### Resource Timing Metrics

#### Page Load Time

**What it measures**: The total time from navigation start to the page fully loading (including all resources).

**Why it matters**: Overall page performance indicator.

**Target**: < 3 seconds for good user experience

***

#### Server Response Time

**What it measures**: Time spent waiting for the server to generate and send the initial HTML response.

**Why it matters**: Slow server processing delays everything else.

**How to improve**:

* Optimize database queries
* Use server-side caching
* Upgrade server resources if needed
* Implement application performance monitoring

***

#### Content Transfer Time

**What it measures**: Time spent downloading the initial HTML document.

**Why it matters**: Large HTML files slow down initial rendering.

**How to improve**:

* Minimize HTML size
* Enable gzip/brotli compression (smoxy does this)
* Reduce inline scripts and styles

***

#### Total Byte Weight

**What it measures**: Total size of all resources loaded on the page (HTML, CSS, JavaScript, images, fonts, etc.).

**Why it matters**: Larger pages take longer to download, especially on slower connections. Each megabyte matters for mobile users.

**Thresholds**:

* 🟢 **Good**: < 1 MB
* 🟡 **Acceptable**: 1-3 MB
* 🔴 **Heavy**: > 3 MB

**How to improve**:

* Optimize and compress images with smoxy's image optimization
* Minify CSS and JavaScript (enable in smoxy settings)
* Remove unused code
* Use modern image formats (WebP, AVIF) (smoxy auto converts images)
* Implement lazy loading
* Use responsive images with `srcset`

***

### Network Timing Metrics

#### DNS Lookup Time

**What it measures**: Time to resolve the domain name to an IP address.

**Why it matters**: DNS lookups add latency before connection can begin.

**Typical values**:

* Cached: 0ms
* First visit: 20-120ms

**How to improve**:

* Use a fast DNS provider
* Implement DNS prefetching for external domains: `<link rel="dns-prefetch" href="//example.com">`
* Reduce number of different domains your page loads resources from

***

#### Initial Connection Time

**What it measures**: Time to establish a TCP connection to the server.

**Why it matters**: Each new connection adds latency.

**Typical values**: 20-200ms depending on geographic distance

**How to improve**:

* Enable HTTP/2 or HTTP/3 for connection reuse
* Use a CDN to reduce geographic distance (smoxy provides this)
* Minimize the number of domains
* Implement connection prewarming: `<link rel="preconnect" href="//example.com">`

***

#### SSL Time

**What it measures**: Time to complete the SSL/TLS handshake.

**Why it matters**: HTTPS adds overhead, but is necessary for security and HTTP/2.

**Typical values**: 50-200ms

**How to improve**:

* Enable TLS 1.3 (faster handshake)
* Use OCSP stapling
* Implement TLS session resumption
* Use modern cipher suites

***

### Device & Context Data

#### Device Type

Your data is automatically segmented by:

* **Desktop**: Traditional computers
* **Mobile**: Smartphones
* **Tablet**: Tablet devices

**Why it matters**: Different devices have vastly different performance characteristics. Mobile devices typically have slower CPUs and network connections.

**Best practice**: Always check performance across all device types, as mobile often performs significantly worse.

***

### Geographic Data

#### Country, City, Location

RUM tracks where your users are located.

**Why it matters**:

* Users farther from your servers experience higher latency
* Regional performance issues can be identified
* CDN effectiveness can be measured

**How to use this data**:

* Identify regions with poor performance
* Optimize CDN configuration
* Consider regional server placement for key markets
* Understand your audience distribution

***

### Network Data

#### ISP & ASN (Autonomous System Number)

Information about the user's Internet Service Provider.

**Why it matters**: Some ISPs have consistently better or worse performance to your servers.

**How to use this data**:

* Identify ISPs with poor connectivity
* Troubleshoot regional network issues
* Optimize routing for major ISPs

***

### Interpreting Your Data

#### The 75th Percentile

smoxy RUM uses the **75th percentile (p75)** for Core Web Vitals, following Google's recommendations.

**What this means**: 75% of your users experience this value or better. This provides a balanced view that isn't skewed by outliers while still accounting for users with slower experiences.

**Example**: If your LCP p75 is 2.0 seconds:

* 75% of users see LCP of 2.0s or faster
* 25% of users see LCP slower than 2.0s

#### Good vs. Poor Classification

Each metric has thresholds that classify performance:

* **Good**: Meeting recommended targets
* **Needs Improvement**: Close to targets but could be better
* **Poor**: Failing to meet minimum standards

**Focus on moving "Poor" metrics to "Needs Improvement" first** - these have the biggest impact on user experience and SEO.

***

### What to Optimize First?

#### Priority Order

1. **Core Web Vitals** (LCP, INP, CLS)
   * Direct SEO impact
   * Strong correlation with user satisfaction
2. **TTFB & Server Response Time**
   * Foundation for all other metrics
   * Often easiest to improve with caching
3. **Total Byte Weight**
   * Major impact on mobile users
   * Improves multiple metrics
4. **Blocking Time & INP**
   * Critical for interactivity
   * Affects user engagement

#### Quick Wins

Start with these high-impact, low-effort optimizations:

✅ Enable image optimization in smoxy\
✅ Enable HTML/CSS/JS minification in smoxy\
✅ Add `width` and `height` to all images\
✅ Enable browser caching\
✅ Compress large images before upload\
✅ Remove unused third-party scripts

***

### Next Steps

* [Using the Analytics Dashboard](https://docs.smoxy.eu/en/real-user-monitoring/using-the-analytics-dashboard) - Learn to navigate RUM data in smoxy
* [Custom Dashboards with Grafana](https://docs.smoxy.eu/en/real-user-monitoring/custom-dashboards-with-grafana) - Build custom visualizations