Measurement and testing

For technical details on these metrics and how to achieve the benchmarks, see the Developer supplement tab.

Measuring and improving user experience (UX) can be challenging — optimising it isn't just about design, but about performance, ease of use, and how well a site meets user expectations.

• UX measurement should be context-driven, rather than method-driven.
• Balanced evaluation combines quantitative data (what users do) with qualitative insights (why they do it).

These additional metrics extend the core LRO performance framework to better reflect the real-world conditions of low-resource users, such as limited bandwidth, low-end devices, unstable connectivity, and high data costs. They focus on areas not fully captured by standard web performance metrics, including data efficiency, resilience, device constraints, interaction simplicity, and perceived performance.

Developers should first target and validate the core performance metrics (page weight, load time, critical rendering performance) before working on these additional metrics. Once baseline targets are met, these metrics can drive deeper improvements in usability, reliability, and inclusivity for low-resource environments.

See the Developer supplement tab for technical guidance on how to measure each of these additional metrics.

Use the standardised profiles below for consistent LRO testing across browsers and environments.

Network conditions

Chrome DevTools (recommended)

Open DevTools

Right-click → Inspect, or press Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac)

Simulate network conditions

1. Go to the Network tab.
2. Locate the Throttling dropdown (default: No throttling).
3. Click Add… or Custom and enter the values from the profiles table above.
4. Select your saved profile from the dropdown.
5. Reload the page to test.

Simulate offline mode

In the Network tab, select Offline and reload the page. Validate fallback behaviour when no connectivity is available.

Simulate CPU throttling (device constraint)

1. Go to the Performance tab.
2. Click the gear/settings icon.
3. Enable CPU throttling (4× or 6× slowdown).
4. Observe: time to interactive, UI responsiveness, and long tasks.

Simulate low-end devices (device toolbar)

1. Toggle device toolbar (Ctrl+Shift+M).
2. Select a device (e.g., low-end Android).
3. Combine with network throttling for a realistic low-resource test.

Firefox DevTools

1. Open DevTools → Network tab.
2. Use the Throttling dropdown — select presets or create a custom profile.
3. Toggle Offline mode to test fallback behaviour.

Safari (Mac)

1. Enable developer tools: Preferences → Advanced → Show Develop menu.
2. Go to Develop → Network Link Conditioner.
3. Choose a preset or create a custom profile to simulate network conditions.

Testing strategy

• Start with Slow 3G as the baseline.
• Validate extreme cases (2G and offline).
• Test mid-tier profiles (Fast 3G / Low 4G).
• Include unstable scenarios (Public Wi-Fi).
• Fix issues that break under Slow 3G first; ensure graceful degradation under 2G.

Code examples

Detect network type

// Check if the Network Information API is available
if (navigator.connection) {
  // Log the effective connection type (e.g., '2g', '3g', '4g', 'wifi')
  console.log('Effective network type:', navigator.connection.effectiveType);
}

Adaptive loading based on network

// Load a lightweight version for slow networks
if (navigator.connection?.effectiveType === '2g') {
  // User has a slow connection — load a lighter version of the site
  loadLiteVersion();
} else {
  // Faster connection — load full-featured version
  loadFullVersion();
}

function loadLiteVersion() {
  // e.g., load smaller images, defer non-critical scripts
}

function loadFullVersion() {
  // e.g., load high-res images, full scripts
}

The Developer Supplement provides practical guidance for implementing LRO principles. It covers how to optimise web performance for low-resource environments and explains why each benchmark matters.

Technical benchmarks reference

Page weight & requests

1. Total page size ≤ 500 KB (initial load)

Why it matters: In low-bandwidth environments, every extra kilobyte directly impacts load time. A 2 MB site might take 30+ seconds on 2G, causing abandonment.

How to achieve:

• Compress images (WebP/AVIF preferred).
• Enable Gzip/Brotli compression on the server.
• Minify and tree-shake CSS & JS.
• Avoid large background images/videos on first load — load them lazily.

2. ≤ 50 HTTP requests on first load

Why it matters: Each request adds round-trip latency. On 3G, latency can be 400ms+ per request, so 100 requests may mean 40 seconds of waiting before content downloads.

How to achieve:

• Combine/minify CSS & JS files where appropriate.
• Use HTTP/2 or HTTP/3 (which handles multiple streams more efficiently).
• Inline small critical assets (SVG icons, tiny CSS) instead of separate requests.
• Defer analytics, ads, and third-party widgets until the main content has loaded.

3. Inline/preload critical CSS, defer non-essential JS

Why it matters: Browsers block rendering until they fetch and parse CSS & JS. External and delayed critical resources mean users see a blank screen for longer.

How to achieve:

• Use tools like CriticalCSS or PurgeCSS to extract minimal CSS for inlining.
• Add <link rel="preload"> for fonts and critical CSS.
• Add defer or async attributes to script tags.
• Lazy-load non-essential widgets, ads, or heavy scripts.

Performance metrics

1. First Contentful Paint (FCP ≤ 2s on 3G)

Time until the first piece of DOM content is rendered. Signals to the user that something is happening. Optimisation tips: minimise critical path resources, compress and preload fonts, use a fast CDN, reduce render-blocking CSS/JS.

2. Largest Contentful Paint (LCP ≤ 2.5s)

Time for the largest visible element to render. Measures when the main content is actually ready. Optimisation tips: optimise hero images, preload LCP assets, reduce TTFB below 600ms, avoid oversized images.

3. Time to Interactive (TTI ≤ 5s on mid-tier device)

Time until the page can reliably respond to user input. Optimisation tips: split code bundles, defer non-critical JavaScript, use web workers for heavy computations, minimise main thread work.

4. Total Blocking Time (TBT ≤ 300ms)

Total time between FCP and TTI where the main thread was blocked by long tasks (>50ms). Optimisation tips: break long JS tasks into smaller chunks, use requestIdleCallback for background work, optimise third-party scripts.

5. Cumulative Layout Shift (CLS ≤ 0.1)

Measures how much visible content unexpectedly shifts during page load. Optimisation tips: always set width/height on images and video, preload fonts to avoid FOUT, avoid dynamically inserting DOM elements above existing content, reserve space for ads and embeds.

JavaScript & resource use

1. JS bundle ≤ 150 KB gzipped (initial load)

Why it matters: Large bundles take longer to download on slow networks. Parsing and executing JS is CPU-intensive — low-tier devices may take seconds even after the download finishes.

How to achieve: Tree-shaking, code splitting, lazy-loading non-critical features, replacing heavy frameworks with lighter alternatives (e.g., Preact instead of React, native JS where possible).

2. No long tasks > 50ms

Why it matters: Long tasks block the main thread, causing UI freezes, input delays, and jank — magnified on mid-tier devices.

How to achieve: Break heavy computations into smaller chunks, use requestIdleCallback for non-urgent background work, offload CPU-heavy logic to Web Workers, reduce expensive DOM operations during load.

3. Memory stable on 512 MB RAM devices

Why it matters: High memory usage causes frequent garbage collection and crashes on entry-level smartphones common in low-resource regions.

How to achieve: Avoid memory leaks (detached DOM nodes, unremoved event listeners), use device-appropriate image sizes, keep JS variables and in-memory caches minimal.

4. Core features work with JS disabled/partial load

Why it matters: On weak networks, JS files may timeout or fail. Accessibility tools and old browsers may not execute JS.

How to achieve: Progressive enhancement — start with semantic HTML, layer JS enhancements. Ensure core navigation and content are server-rendered. Provide server-side fallbacks for forms, links, and routing.

Network resilience

1. Test on slow 3G (400 kbps, 400ms RTT)

Use Chrome DevTools → Network Throttling → Slow 3G. Use WebPageTest with Moto G4/3G profile. Add performance budgets that fail builds if page exceeds size/load thresholds.

2. Progressive rendering: content visible early

Inline critical HTML & CSS (above-the-fold). Defer non-essential JS and images. Use skeleton screens or content placeholders. Stream HTML as chunks are ready rather than as one large response.

3. Service worker caching for critical assets

Use Workbox or manual service worker setup. Cache HTML shell + essential assets (CacheFirst strategy). Apply StaleWhileRevalidate for frequently updated resources (API calls). Keep the cache size small — avoid blindly caching everything.

4. Retry/fallback for images & data fetches

For images: use <picture> with multiple formats/sizes and provide low-res placeholders as fallbacks. For fetches/API calls: implement retry logic with exponential backoff, show cached/offline data where possible, and gracefully degrade the UI ("content unavailable, try again").

Accessibility & usability

1. Keyboard-only navigation works

Why it matters: Many low-resource users rely on non-mouse input. Keyboard support also improves screen reader compatibility.

How to achieve: Ensure focus styles are always visible, maintain logical tab order, provide skip-to-content links, and ensure interactive elements (menus, forms, modals) can be operated with keyboard only.

2. Text accessible without images/CSS/JS

Why it matters: On poor connections, resources often fail to download. Text-first browsers, screen readers, and search crawlers rely on semantic HTML.

How to achieve: Use semantic HTML tags (<h1>, <p>, <button>, <nav>), provide alt text for images, ensure text contrast is high enough without CSS, never hide essential content behind client-side rendering alone.

3. Optional low-bandwidth mode (text-first)

Why it matters: Critical for users on 2G/3G, satellite internet, or expensive metered data.

How to achieve: Offer a "Low-bandwidth mode" or "Text-only mode" toggle. Auto-detect via the Save-Data HTTP header. Use conditional loading to serve only core text and small assets in this mode.

Energy & device constraints

1. Avoid autoplay video/animations on load

Why it matters: Videos and animations consume CPU, GPU, and bandwidth — on weak devices they cause lag, stutters, or crashes; on mobile they drain battery fast.

How to achieve: Disable autoplay by default; use a static poster image instead of loading video immediately; prefer CSS transitions or SVG animations over heavy JS/Canvas effects; give users explicit "Play video" control.

2. Minimal CPU/GPU-intensive tasks

Why it matters: Low-end devices have weak CPUs/GPUs, often without hardware acceleration. Heavy computation leads to high battery drain and poor responsiveness.

How to achieve: Avoid infinite loops or constant polling; minimise reflows and repaints; avoid large shadows, blurs, or filters that trigger GPU acceleration; aim for a stable 30–60 FPS with minimal dropped frames.

3. Works on low-end Android (emulator/device test)

Why it matters: The majority of users in low-resource regions browse on low-end Android phones. Sites that feel fine on MacBooks or flagship iPhones may be unusable on these devices.

How to achieve: Test with Chrome DevTools → CPU throttling (4× or 6×) + network throttling. Use emulated Android Go devices (Moto E, Nokia C series, etc.). Run Lighthouse in simulated low-end hardware mode.

Testing & tooling

1. Run Lighthouse with throttling (3G / mid-tier mobile)

In Chrome DevTools → Lighthouse tab, set Network to Slow 3G (400 kbps, 400ms RTT) and CPU to 4× or 6× slowdown with Mobile emulation. Pay attention to FCP, LCP, TTI, CLS, and JavaScript bundle sizes.

2. Run WebPageTest (2G/3G, Moto G4 profile)

Configure WebPageTest with device Moto G4 (or similar), connection 2G/3G or custom bandwidth, and a location representative of your users (India, Africa, LATAM). Review waterfall charts for large/slow assets and use the filmstrip view to check how quickly content becomes visible.

3. Monitor Core Web Vitals (PageSpeed Insights / Search Console)

Run PageSpeed Insights regularly to compare lab vs field results. Use Search Console → Core Web Vitals report for long-term tracking. Segment performance by device type and region. Thresholds: FCP ≤ 2s, LCP ≤ 2.5s, CLS ≤ 0.1, TBT ≤ 300ms.

How to measure additional metrics

Data Cost per Page Load

Open Chrome DevTools → Network tab. Enable "Disable cache" and throttle to Slow 3G / 2G. Reload the page and check Transferred or Total bytes. Record: total MB downloaded (HTML + CSS + JS + images + fonts + APIs).

Repeat Visit Data Usage

Load page once, then reload with cache enabled. Check Network tab → Transferred size (excluding "from disk cache"). Record: KB transferred on second load.

Image Bytes Ratio

Filter the Network tab by Img. Sum image bytes and divide by total page bytes. Formula: Image Bytes / Total Bytes × 100.

Partial Load Usability

Disable JavaScript (DevTools → Settings → Disable JS). Reload and count total key content sections vs visible/usable sections. Formula: Visible core sections / Total core sections × 100.

Retry Friendliness

Throttle to Slow 3G, simulate a network drop, and observe auto-retries, error messages, and exponential backoff behaviour. Score: Yes / Partial / No.

Peak Memory Usage

Open Chrome Performance → Record → Reload page → Stop recording. Inspect the Memory graph. Record: peak MB usage.

JS Execution Time

Run Lighthouse and check Total Blocking Time and JS execution time. Or inspect the CPU flame chart in the Performance tab. Record: seconds of JS execution.

DOM Node Count

Run document.getElementsByTagName('*').length in the DevTools Console. Record: number of DOM nodes (target ≤ 800).

CPU Wakeups per Minute

In Chrome Performance, record an idle page for 1 minute and count CPU spikes. Record: wakeups/minute (target ≤ 5).

Network Requests After Idle

Load the page, wait 30–60 seconds, and observe new requests in the Network tab. Record: None / Minimal / Frequent.

Old Browser Support

Test on Android 8 / Chrome 80 in BrowserStack or Sauce Labs. Verify the page loads and core content is visible. Score: Full / Partial / Broken.

No-JS Mode Coverage

Disable JS, reload, and count visible content sections. Record: percentage (target ≥ 80%).

Time to First Meaningful Text

Run Lighthouse and observe First Contentful Paint, then validate visually. Record: seconds (target ≤ 1s).

Blank Screen Time

Run WebPageTest video capture and observe video frames until content appears. Record: milliseconds (target ≤ 500ms).

Low-Data Mode Toggle

Look for the toggle in the UI, test it, and verify a reduced payload. Score: Yes / Hidden / No.

Data Usage Disclosure

Trigger large content and observe whether a warning or message is displayed. Score: Always / Sometimes / Never.