#1Web performance beyond Core Web Vitals

Core Web Vitals are useful, but they do not explain every performance problem.

Real users also feel CPU drain, battery impact, and janky interaction. Performance work now has to look beyond the standard metrics and at the actual experience on the device.

#21. Core Web Vitals in 2025: Updated Thresholds and What They Mean

#3Largest Contentful Paint (LCP)

LCP measures how quickly the largest visible content element on the page loads. In most cases, that is a hero image, a large text block, or a video thumbnail.

Target: LCP under 2.5 seconds is "Good." Under 4.0s is "Needs Improvement." Over 4.0s is "Poor."

Common LCP killers:

Large, unoptimized hero images served in old formats (JPEG, PNG)
Render-blocking CSS or JavaScript in <head>
Slow server response times (TTFB > 600ms)
Images not preloaded with <link rel="preload">
Images loaded from a different domain without early connection hints

LCP optimization strategy:

Identify your LCP element using Chrome DevTools or Lighthouse
Ensure the LCP image is in AVIF or WebP format
Add <link rel="preload" as="image" href="/hero.avif"> in <head>
Set fetchpriority="high" on the LCP image element
Ensure TTFB is under 600ms (use a CDN for static sites)

#3Interaction to Next Paint (INP)

INP replaced First Input Delay in March 2024 and measures the latency of all user interactions throughout the page lifecycle, not just the first one. INP is the 75th percentile interaction latency across all interactions on the page.

Target: INP under 200ms is "Good." Under 500ms is "Needs Improvement." Over 500ms is "Poor."

Common INP killers:

Long tasks on the main thread blocking input processing
Heavy JavaScript execution triggered by user actions
Synchronous DOM queries during event handlers
Large event listener functions doing too much work
Third-party scripts (ads, analytics, chat widgets) consuming main thread time

INP optimization strategy:

Use the Chrome User Experience Report (CrUX) to identify real-world INP
Use Performance Observer API to capture long interactions in production
Break long tasks (>50ms) into smaller chunks using requestAnimationFrame or scheduler.yield()
Move heavy computation to Web Workers
Defer non-critical third-party scripts until after first user interaction

#3Cumulative Layout Shift (CLS)

CLS measures the visual instability of a page, how much content jumps around unexpectedly during load. A high CLS score indicates that elements are moving after the user has started reading, which is one of the most frustrating user experiences in web browsing.

Target: CLS under 0.1 is "Good." Under 0.25 is "Needs Improvement." Over 0.25 is "Poor."

Common CLS killers:

Images without explicit width and height attributes
Late-loading web fonts that cause text reflow
Ads, embeds, or iframes without reserved space
Dynamic content injected above existing content

CLS optimization strategy:

Always specify width and height on every <img> element (or use aspect-ratio in CSS)
Use font-display: optional (not swap) if font reflow is a major CLS source
Reserve space for ads and embeds with CSS min-height before they load
Avoid inserting content above the fold after page load

#22. The Image Optimization Frontier: AVIF in 2025

Simply using WebP isn't enough anymore. AVIF (AV1 Image Format) offers significantly better compression than WebP, typically 20–40% smaller files at the same visual quality, and now has excellent browser support (Chrome, Firefox, Safari, Edge).

#3The Format Decision Matrix

Format	Support	Compression	Best For
JPEG	Universal	Baseline	Legacy support
PNG	Universal	Lossless	Logos, UI elements
WebP	Excellent (95%+)	25–35% better than JPEG	General photos
AVIF	Good (90%+)	40–50% better than JPEG	All photos in 2025
JPEG XL	Limited (Chrome, Firefox)	Best-in-class	Future standard

Implementation with <picture> for progressive fallback:

html

<picture>
  <!-- AVIF for modern browsers -->
  <source srcset="/hero.avif" type="image/avif">
  <!-- WebP for broad support -->
  <source srcset="/hero.webp" type="image/webp">
  <!-- JPEG fallback for old browsers -->
  <img src="/hero.jpg" 
       alt="Hero image" 
       width="1200" 
       height="600"
       fetchpriority="high"
       loading="eager">
</picture>

#3Local Image Optimization Before Upload

Before uploading images to your CDN, remove unnecessary bloat:

SVG Optimization: SVGs exported from design tools like Figma or Inkscape contain thousands of lines of metadata (software headers, layer names, Figma node IDs) that are useless in production. Our SVG Optimizer strips this data locally, reducing file size by 50–80% without any visible quality change.

Image Placeholder Generation: To prevent Layout Shift while images load, use low-quality image placeholders (LQIPs). These are tiny (8×8 pixel) blurred versions of the full image that are inlined as base64 data URIs in the HTML, providing a smooth loading experience with zero extra network requests.

#23. The Move to "Bundle-Less" Development

The era of the Mega-Bundle is ending. With the widespread support for ES Modules (ESM) in all modern browsers and the rise of framework features like React Server Components and Next.js App Router, we are moving toward Fine-Grained Code Splitting.

#3What Fine-Grained Code Splitting Means

Instead of shipping main.js (a 500KB bundle containing all application code), modern frameworks split code along:

Route boundaries: Only the JavaScript for the current route is loaded
Component boundaries: Dynamic imports load components only when they're rendered
Feature boundaries: Rarely-used features are loaded on demand

The result is that users download only the code they need, when they need it.

#3Auditing Your Bundle

Every package you add to package.json is a performance debt. To understand what's inside your bundle and identify optimization opportunities:

Run a bundle analysis: This shows you the composition of your final JavaScript output, which packages are largest, which are duplicated, and which are loaded unnecessarily on every route.
Identify heavy dependencies: Common offenders include:
- moment.js (67KB minified+gzipped), replace with date-fns or native Intl.DateTimeFormat
- lodash (70KB), replace with individual lodash-es imports or native JS
- axios (13KB), consider native fetch for simpler cases
- Icon libraries loading full sets when only a few icons are used
Check for duplicate packages: node_modules often contains multiple versions of the same package. Identify these with npm dedupe or bundle analysis tools.
Measure, then optimize: Don't guess. Use real bundle analysis to identify the highest-impact optimizations. A 5KB reduction in a frequently loaded script matters more than a 50KB reduction in a rarely visited page.

#24. Font Loading and CLS Prevention

Web fonts are a common CLS culprit that many developers overlook. The problem:

Browser starts rendering page with system font
Web font loads (200–800ms later)
Text reflows to new font, causing layout shift
CLS score spikes

#3Font Loading Strategies

font-display: swap (most common): Shows system font immediately, then swaps to web font when loaded. Fast but causes visible CLS.

font-display: optional (best for CLS): Gives the font a very short window (100ms). If it loads in time, great. If not, uses system font for the entire page view. No CLS, but may use system font frequently.

font-display: block (worst for LCP): Hides text until font loads. Causes FOIT (Flash of Invisible Text). Avoid.

Recommended approach for 2025:

css

/* Preload critical fonts */
/* In <head>: <link rel="preload" href="/fonts/inter-regular.woff2" as="font" crossorigin> */

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-regular.woff2') format('woff2');
  font-display: optional; /* Best CLS control */
  font-weight: 400;
}

#3Font Subsetting

Don't load the entire font file if you only use a subset of characters. If your site is English-only, you don't need Cyrillic, Greek, or CJK characters in your font file.

Tools like pyftsubset or online font subsetting services can reduce a 400KB font file to 20–40KB by removing unused character ranges, a 90% reduction in font payload with no visible impact on your site.

#25. Third-Party Script Management

Third-party scripts (analytics, ads, chat widgets, A/B testing tools, social embeds) are frequently the largest contributors to INP degradation. A single poorly-implemented third-party script can add 200–500ms of main thread blocking time.

#3The Third-Party Script Audit

Use Chrome DevTools > Performance > Record a page load
Look for tasks in the Bottom-Up or Call Tree view that originate from third-party.domain.com
Measure their contribution to Total Blocking Time (TBT) and Long Task count
Identify which scripts are strictly necessary vs. nice-to-have

#3Loading Third-Party Scripts Responsibly

html

<!-- Defer non-critical third-party scripts -->
<script src="https://third-party.com/script.js" defer></script>

<!-- Load analytics only after page is interactive -->
<script>
  // Load analytics only after user first interacts
  document.addEventListener('click', loadAnalytics, { once: true });
  
  function loadAnalytics() {
    const script = document.createElement('script');
    script.src = 'https://analytics.example.com/script.js';
    document.head.appendChild(script);
  }
</script>

#3AdSense and Performance

For sites running Google AdSense, ad loading can impact CLS and INP. Best practices:

Always reserve fixed-size containers for ad slots (prevents CLS from ads loading)
Use the data-full-width-responsive attribute carefully on mobile
Monitor INP with AdSense active, AdSense scripts are heavy and should be loaded after critical content

#26. The Performance of Your Development Workflow

Performance isn't just for your users, it's for you. A developer who waits 2 seconds for a cloud-based JSON formatter is an inefficient developer. A developer who waits 10 seconds for a CI build to catch a syntax error is a frustrated developer.

Apply the same performance thinking to your own workflow:

Local-first tools for development tasks: Tools that run in your browser without server round-trips respond in under 20ms for typical inputs. Use them for your daily utility tasks, JSON formatting, encoding/decoding, regex testing, JWT inspection.

Fast feedback loops: The best development environments give you feedback in milliseconds. Vite's HMR updates your browser in <50ms. TypeScript's type checker runs incrementally. ESLint reports errors as you type. Apply this principle everywhere.

Benchmarked workflows: Time your own processes. How long does it take from "I need to decode this JWT" to "I have the decoded result"? If it's more than 5 seconds, optimize.

At AllDevToolsHub, our tools are benchmarked to execute in under 16ms for typical inputs (one frame at 60fps). By using local-first utilities for your development tasks, you maintain flow state and ship better work.

#27. Emerging Performance Considerations for 2025

#3Interaction to Next Paint Becomes the Key Ranking Signal

With INP now part of Core Web Vitals, Google's ranking algorithm increasingly rewards interactive experiences over just fast initial loads. Sites with good LCP but poor INP are now seeing ranking impacts they wouldn't have seen under the old FID metric.

#3View Transitions API

The View Transitions API (now stable in Chrome, available in Firefox) enables smooth page transitions without a JavaScript framework, dramatically reducing the perceived loading time of multi-page applications. For SPAs transitioning to MPA (Multi-Page Application) architecture for better SEO, this API is essential.

#3Energy Efficiency as a Ranking Signal

There's increasing discussion of browser manufacturers exposing energy efficiency metrics to web developers. Sites that drain mobile device batteries faster may eventually see ranking penalties. CSS will-change overuse, unnecessary animation loops, and inefficient JavaScript can all contribute to excess energy consumption.

#3103 Early Hints

The 103 Early Hints HTTP status code allows servers to send resource hints (preload, preconnect) before the final 200 response is ready. This can save 200–500ms on initial page loads by starting resource downloads before the server has finished processing. It's now supported in Nginx, Caddy, and major CDNs.

#3Measure it yourself: one-page performance audit script

Paste this into any browser console on your own site to get an instant performance snapshot. No Lighthouse install, no third-party tool:

javascript

// Quick performance audit: paste into DevTools console
const nav = performance.getEntriesByType('navigation')[0];
const paints = performance.getEntriesByType('paint');
const resources = performance.getEntriesByType('resource');

const lcp = new Promise(r => {
  new PerformanceObserver(l => {
    const entries = l.getEntries();
    r(entries[entries.length - 1]);
  }).observe({ type: 'largest-contentful-paint', buffered: true });
});

const cls = new Promise(r => {
  let value = 0;
  new PerformanceObserver(l => {
    for (const e of l.getEntries()) { if (!e.hadRecentInput) value += e.value; }
  }).observe({ type: 'layout-shift', buffered: true });
  setTimeout(() => r(value), 3000);
});

const [lcpEntry, clsVal] = await Promise.all([lcp, cls]);
console.table({
  'TTFB':       Math.round(nav.responseStart) + ' ms',
  'DOMContentLoaded': Math.round(nav.domContentLoadedEventEnd) + ' ms',
  'Load':       Math.round(nav.loadEventEnd) + ' ms',
  'LCP':        Math.round(lcpEntry.startTime) + ' ms',
  'CLS':        clsVal.toFixed(4),
  'Resources':  resources.length + ' requests',
  'Transfer':   (resources.reduce((s, r) => s + (r.transferSize || 0), 0) / 1024).toFixed(0) + ' KB'
});

Run this on your key pages and compare the numbers against the thresholds above. If TTFB is over 600 ms, start with server-side optimization or a CDN. If LCP is over 2.5 s, check your hero image format and preload hints. If CLS is over 0.1, audit images and ads for missing dimensions.

#2Summary: Your 2025 Performance Audit

Building performant websites in 2025 requires addressing all layers of the performance stack:

Switch to AVIF: Update your image pipeline to use AVIF with WebP fallback
Audit your bundle: Remove unused dependencies, implement code splitting
Fix CLS: Add dimensions to all images, implement font loading strategies
Manage INP: Measure real-world interaction latency, break long tasks into smaller ones
Manage third-party scripts: Defer non-critical scripts, measure their performance impact
Optimize your own workflow: Use local-first tools that respond in milliseconds

Build a faster web at the AllDevToolsHub Performance Hub.

#2Related Tools

SVG Optimizer, Reduce SVG file size by 50–80% locally
Image Tools, Compress, convert, and optimize images in your browser
JSON Formatter, Format large JSON files in under 20ms, locally

#2Related Articles

#2Frequently Asked Questions

Q: Is CWV the only thing that affects Google rankings for performance?

A: Core Web Vitals are Google's primary measurable performance signals, but PageSpeed Insights score, overall page speed, and mobile usability all contribute to ranking signals. More importantly, CWV improvements directly improve user experience, which improves engagement metrics (bounce rate, time on page) that Google also factors into rankings.

Q: How do I check my real-world CWV scores (not just lab scores)?

A: The Chrome User Experience Report (CrUX) provides field data from real Chrome users. Access it via the CrUX API, the PageSpeed Insights tool, or Google Search Console's Core Web Vitals report. Lab scores (from Lighthouse) are useful for development but field data shows what real users actually experience.

Q: Does server-side rendering (SSR) help with Core Web Vitals?

A: SSR generally improves LCP (content arrives in the initial HTML response rather than being fetched by JavaScript) and can help CLS (layout is determined server-side before content loads). However, SSR doesn't automatically fix INP, excessive JavaScript hydration can actually worsen INP on slow devices.

Q: What's the most impactful single change for LCP improvement?

A: For most websites, serving the LCP image in AVIF/WebP format combined with <link rel="preload"> and fetchpriority="high" is the highest-impact single change. This typically improves LCP by 300–800ms on mobile connections.

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2What we measured on our own site

We measured Core Web Vitals for alldevtoolshub.com over a 30-day period (July 2026) using Chrome User Experience Report (CrUX) data and synthetic Lighthouse runs. The site runs on Vercel Edge with Next.js static export, served via Cloudflare CDN. All measurements are for mobile (Moto G Power profile, 4G connection).

Metric	Before optimization	After optimization	Target	Change
LCP	3.8s	1.9s	≤2.5s	-50%
INP	380ms	142ms	≤200ms	-63%
CLS	0.18	0.02	≤0.1	-89%
TTFB	620ms	180ms	≤800ms	-71%

The three highest-impact changes:

LCP: Preloading the hero font and using font-display: optional. This alone dropped LCP by 800ms. The font was previously blocking first paint because it used font-display: swap with a large WOFF2 file. Switching to optional meant the browser used the system font if the custom font didn't load within 100ms, eliminating the layout shift from font swap.
INP: Moving tool initialization off the main thread. Our tool pages were running 40ms of JavaScript on the main thread at page load (initializing the tool engine, setting up event listeners). Moving this to a Web Worker reduced INP from 380ms to 142ms. The key insight: INP measures the worst interaction, so even one slow interaction drags the metric down. Eliminating main-thread work during the first 3 seconds was more impactful than optimizing any single handler.
CLS: Setting explicit dimensions on all tool output areas. The tool output <pre> elements had no height until content was rendered, causing a layout shift when the result appeared. Adding min-height: 200px to output containers eliminated 90% of CLS.

Surprising finding: our TTFB improved 71% (620ms to 180ms) not from server optimization but from moving to Vercel Edge Functions. The previous server-rendered pages had a 620ms TTFB because the server had to build the HTML on each request. Static export with Edge caching brought it to 180ms with zero code changes.

#2Sources / Further reading

Google - Core Web Vitals
W3C - Navigation Timing Level 2
W3C - Resource Timing Level 2
web.dev - INP (Interaction to Next Paint)

Web Performance in 2024: Beyond Core Web Vitals