Web Performance & Core Web Vitals in 2025 – Why Speed Still Wins

Web application performance in 2025 is not optional – it's a business requirement. Despite widespread fast internet and modern frameworks, slow websites still cost companies millions in lost conversions and Google rankings. Core Web Vitals are no longer just "nice to have" – they're a ranking factor that directly impacts search visibility and user experience.

At MDS Software Solutions Group, we treat performance as an architectural foundation, not "optimization at the end". In this article, we show why performance matters, what real problems we see in client projects, and how a modern tech stack (Next.js, .NET, Redis, CDN) solves these challenges.

The Myth: "Performance is already solved"

The truth is different. Despite powerful frameworks and cloud infrastructure, most web applications in 2025 have performance problems:

• Overloaded frontends – 5 MB JavaScript, 200+ external scripts
• No SSR/ISR – everything rendered on the client side
• Unoptimized images – PNG/JPG instead of WebP/AVIF
• Third-party scripts – analytics, chatbots, pixel tracking blocking rendering
• Poor hosting – cheap shared hosting instead of CDN + edge computing
• No caching – every request hits the database

Result? LCP > 4s, INP > 500ms, CLS > 0.25 – the site fails Core Web Vitals, loses Google rankings and users.

Core Web Vitals in 2025 – What Really Matters

Google updated Core Web Vitals metrics in 2024. Here's what counts in 2025:

1. LCP (Largest Contentful Paint) – ≤ 2.5s

What it measures: Time to load the largest element visible on screen (image, text, video).

Typical problems:

• Unoptimized images (JPEG instead of WebP)
• No preload for critical assets
• Slow Time to First Byte (TTFB) – server responds > 600ms
• Render-blocking CSS/JS

Solutions:

• Next.js Image – automatic optimization, lazy loading, WebP/AVIF
• Static Generation (SSG) – pages generated at build time, served from CDN
• CDN with edge caching – Vercel Edge, Cloudflare, AWS CloudFront
• Preload critical fonts/images – <link rel="preload">

Example: E-commerce with 500 products. Before: LCP 4.2s. After Next.js + Vercel Edge: LCP 1.1s.

2. INP (Interaction to Next Paint) – ≤ 200ms

INP replaced FID (First Input Delay) as the interactivity metric. It measures time from user interaction (click, tap) to when the browser displays the effect of that interaction.

Typical problems:

• Heavy JavaScript operations blocking main thread
• No debounce/throttle in event handlers
• Large bundle sizes – React + 50 libraries
• Synchronous operations on large lists

Solutions:

• Code splitting – load code only when needed
• React Server Components – zero JavaScript for server components
• Web Workers – heavy operations off main thread
• Virtual scrolling – only visible elements in DOM
• Debounce/throttle – limit event frequency

Example: SaaS platform with dashboard. Before: INP 450ms. After RSC + code splitting refactor: INP 85ms.

3. CLS (Cumulative Layout Shift) – ≤ 0.1

What it measures: Visual stability – whether elements "jump" during page load.

Typical problems:

• Images without width/height
• Dynamic content insertion (ads, banners)
• Web fonts loaded asynchronously (FOIT/FOUT)
• CSS animations changing layout

Solutions:

• Aspect ratio containers – aspect-ratio: 16/9;
• Font display: swap + preload fonts
• Reserved space for ads – placeholder with fixed height
• Transform instead of top/left – GPU-accelerated animations
• Next.js Image – automatic aspect ratio preservation

Example: News portal. Before: CLS 0.34. After fixing image dimensions + font strategy: CLS 0.03.

Real Performance Problems in Client Projects

Problem 1: Overloaded Single Page Applications (SPA)

Symptoms:

• Bundle size > 3 MB gzipped
• TTI (Time to Interactive) > 8s on 3G
• Lighthouse Performance Score < 50

What happened:

• All components loaded at startup
• No SSR – SEO crawlers see empty page
• Client-side routing – every URL change requires full JavaScript evaluation

Solution: Next.js App Router + React Server Components

• SSR/ISR – HTML generated on server or at build time
• Server Components – zero JavaScript for non-interactive parts
• Route-based code splitting – automatic split per route
• Streaming – progressive HTML sending to browser

Result: Bundle size -70%, TTI < 2s, Lighthouse 95+.

Problem 2: Unoptimized Hosting and Infrastructure

Symptoms:

• TTFB > 1000ms
• No gzip/brotli compression
• Single geographic region for global users
• Every request hits the database

What happened:

• Cheap shared hosting without CDN
• No cache layer (Redis, Memcached)
• Monolithic backend without horizontal scaling
• Database queries without indexes

Solution: Cloud + CDN + Cache

• Vercel Edge / Cloudflare Workers – edge computing closer to users
• Redis – cache query results, session storage
• PostgreSQL connection pooling – pgBouncer, Supabase Pooler
• CDN for static assets – Cloudflare, AWS CloudFront

Result: TTFB < 200ms, 99.9% uptime, global delivery.

Problem 3: Third-Party Scripts Killing Performance

Symptoms:

• Blocking scripts in <head>
• Google Analytics, Facebook Pixel, chatbots, heatmaps loaded synchronously
• Performance degradation: -20 Lighthouse points per script

What happened:

• Marketing team adds more tracking scripts
• No control over loading priorities
• Scripts loaded even when not needed

Solution: Lazy Loading + Partytown

• Partytown – third-party scripts in Web Worker (off main thread)
• Lazy load – loading only when user scrolls to section
• Server-side tracking – analytics without JavaScript (Plausible, Umami)
• Consent-based loading – load only after user consent

Result: Performance +35 points, INP improvement 200ms → 80ms.

How Modern Stack Solves Performance Problems

Our implementations are based on a proven, optimized stack:

Frontend: Next.js 15 + React 19

Why Next.js?

• SSR/ISR/SSG – rendering on server or at build time
• React Server Components – zero JavaScript for non-interactive parts
• Automatic code splitting – per route, per component
• Image optimization – Next.js Image automatically converts to WebP/AVIF
• Font optimization – next/font eliminates FOIT/FOUT
• Edge Runtime – functions executed on edge close to users

Typical setup:

// app/page.tsx - Server Component (zero JS shipped)
export default async function HomePage() {
  const data = await fetchData(); // Direct DB access
  return <ProductList products={data} />;
}

// components/ProductList.tsx - Server Component
export function ProductList({ products }) {
  return products.map(p => <ProductCard key={p.id} {...p} />);
}

// components/AddToCart.tsx - Client Component (only this ships JS)
'use client';
export function AddToCart({ productId }) {
  return <button onClick={() => addToCart(productId)}>Add</button>;
}

Result: Bundle size -60%, LCP < 1.5s, perfect SEO.

Backend: .NET Minimal API + Redis

Why .NET?

• Blazing fast – performance benchmarks top tier
• Async/await – non-blocking I/O
• EF Core – ORM with connection pooling
• Output caching – [OutputCache] attribute for API responses
• Health checks – application health monitoring

Redis as cache layer:

// Cache frequently accessed data
public async Task<Product[]> GetProducts()
{
    var cacheKey = "products:all";
    var cached = await _redis.GetAsync<Product[]>(cacheKey);
    if (cached != null) return cached;

    var products = await _db.Products.ToArrayAsync();
    await _redis.SetAsync(cacheKey, products, TimeSpan.FromMinutes(10));
    return products;
}

Result: Response time < 50ms (cache hit), 200-500ms (cache miss).

Database: PostgreSQL + Connection Pooling

Optimizations:

• Indexes – B-tree, GiST for full-text search
• Prepared statements – eliminate parsing overhead
• Connection pooling – pgBouncer, Supabase Pooler
• Materialized views – pre-computed queries for analytics

CDN and Edge: Vercel Edge / Cloudflare

Why edge?

• Low latency – servers in 200+ locations globally
• DDoS protection – automatic protection
• Automatic caching – static assets cached at edge
• Edge Functions – API endpoints close to users

Typical setup:

• Next.js app deployed on Vercel (automatic edge optimization)
• Static assets (images, fonts, CSS) cached on Vercel Edge
• API Routes cached with revalidate strategy

More about technologies:

• Next.js – why we choose this framework?
• .NET API – backend for modern applications
• PostgreSQL – database for enterprise applications
• Redis – cache and queues for high performance

Performance = Money (Data and Examples)

Performance isn't a "nice add-on" – it's direct impact on revenue.

Impact on Conversion

Google research (2023-2024):

• +0.1s delay = -7% conversion for e-commerce
• +1s load time = -10% revenue for retail
• 53% of users abandon site if it loads > 3s

Examples from our implementations:

• E-commerce (electronics): LCP reduction from 3.8s to 1.2s → +23% conversion rate
• SaaS (B2B): INP improvement from 420ms to 95ms → +17% sign-up rate

Impact on SEO and Google Ranking

Core Web Vitals = ranking factor:

• Sites meeting CWV have average +20% more organic traffic
• Poor CWV = lower positions for competitive keywords
• Mobile-first indexing = mobile performance determines ranking

Case study: B2B portal (SaaS). Before optimization: 35% keywords in TOP10. After CWV improvement (all "green"): 62% keywords in TOP10 within 4 months.

Mobile-First Reality

80% of users access from mobile (2025 average). Mobile connections:

• Slower (4G/5G coverage uneven)
• More expensive (limited data plans)
• Less patient users (on-the-go browsing)

Mobile optimization must-haves:

• Lighthouse Mobile Score 90+
• LCP < 2.5s on 4G
• Bundle size < 500 KB (gzipped)
• Responsive images with srcset

How MDS Software Solutions Group Approaches Performance

Performance-First Architecture

We don't "optimize at the end" – we design with performance from the start:

1. SSR/SSG by default – render HTML on server or at build time
2. Minimal JavaScript – only what's necessary for interaction
3. Cache layers – Redis for queries, CDN for assets
4. Image/font optimization – automatic conversion, preload
5. Monitoring – continuous performance tracking (Lighthouse CI, Vercel Analytics)

Performance Budget

We define limits at project stage:

• Bundle size: < 200 KB (gzipped) for initial load
• LCP: < 2.0s
• INP: < 150ms
• CLS: < 0.05
• Lighthouse Score: 95+ (desktop), 90+ (mobile)

If new feature exceeds budget – we refactor or decline.

Measurable Results

All our projects have performance dashboards:

• Real User Monitoring (RUM) – data from actual users
• Lighthouse CI – automated tests on every deploy
• Core Web Vitals tracking – Google Search Console integration
• Custom metrics – API response time, database query time

Reporting: Monthly reports with performance metrics + correlation with business KPIs (conversion, revenue).

Practical Tips: How to Improve Performance Today

Quick Wins (1-2 days work)

1. Image optimization

   • Convert PNG/JPG → WebP/AVIF
   • Compression with TinyPNG, Squoosh
   • <img> → <Image> (Next.js) with lazy loading

2. Font optimization

   • font-display: swap + preload critical fonts
   • Font subsetting (only used characters)
   • Variable fonts (one file instead of multiple)

3. Lazy load third-party scripts

   • Google Analytics, chatbots loaded after user interaction
   • <script async defer> for non-critical scripts

4. Enable compression

   • Gzip/Brotli on server
   • Check: Content-Encoding: br in response headers

Medium-Term (2-4 weeks)

1. Implement SSR/SSG

   • Migration from SPA (React) to Next.js App Router
   • Server Components for static parts
   • ISR for dynamic data with revalidation

2. Cache layer

   • Redis for database queries
   • CDN for static assets
   • HTTP caching headers (Cache-Control, ETag)

3. Code splitting and tree shaking

   • Dynamic imports for heavy components
   • Remove unused dependencies
   • Bundle analysis (next-bundle-analyzer, webpack-bundle-analyzer)

Long-Term (1-3 months)

1. Edge-first architecture

   • Deploy on Vercel/Cloudflare
   • Edge Functions for API
   • Global CDN for all assets

2. Performance monitoring

   • Real User Monitoring (RUM) setup
   • Alerting for performance regressions
   • A/B testing performance optimizations

3. Progressive Web App (PWA)

   • Service Workers for offline support
   • App-like experience on mobile
   • Push notifications

When NOT to Optimize Performance?

Honesty: Not every project requires extreme optimization.

Performance optimization doesn't make sense if:

1. Internal tools with few users (< 50) on fast connection
2. MVP/prototype – focus on idea validation, not performance
3. Content-heavy sites where content > performance (documentation, blogs)
4. Optimization cost > ROI – for niche B2B tools without SEO pressure

Questions to ask:

• How many daily users?
• What % are mobile users?
• Does SEO matter for the business?
• What's the bounce rate?
• Does slow site cost conversions?

If answers indicate low priority – better invest in functionality.

Tools for Measuring and Monitoring Performance

Testing Tools (Before Deployment)

• Lighthouse – Chrome DevTools, automated CI
• WebPageTest – detailed waterfall analysis
• PageSpeed Insights – Google's official tool with CWV data
• GTmetrix – comprehensive performance report

Monitoring Tools (Production)

• Vercel Analytics – automatic for Next.js on Vercel
• Google Search Console – Core Web Vitals report
• Sentry Performance – transaction tracking, slow queries
• New Relic / Datadog – full-stack APM

Real User Monitoring (RUM)

• Google Analytics 4 – web vitals custom events
• Plausible / Umami – lightweight, privacy-friendly
• Custom RUM – web-vitals library + own endpoint

Summary

Web performance in 2025 is non-negotiable:

• Core Web Vitals – LCP, INP, CLS – direct impact on SEO ranking
• Conversion impact – every second of delay = lost revenue
• Mobile-first – 80% of users are mobile, slow connections

Common problems:

• Overloaded SPA without SSR
• No cache layers (Redis, CDN)
• Third-party scripts blocking rendering
• Poor hosting and infrastructure

Solutions:

• Next.js 15 – SSR, RSC, automatic optimizations
• .NET + Redis – fast backend with cache layer
• PostgreSQL + connection pooling – optimized database
• Vercel Edge / Cloudflare – global CDN, edge computing

Results: Lighthouse 95+, LCP < 1.5s, INP < 100ms, CLS < 0.05, +20-30% conversion.

Our approach: Performance-first architecture, performance budgets, continuous monitoring, measurable ROI.

Want to improve your application's performance? Contact us – we'll conduct a performance audit and propose an action plan.

Related Articles

• Next.js – modern web applications
• .NET API – backend for enterprise
• Redis – cache and queues
• PostgreSQL – database for AI applications
• Web Development Trends 2024

Further Resources

• Web.dev – Core Web Vitals Guide
• Next.js Performance Documentation
• Chrome DevTools Performance
• Google PageSpeed Insights