How to Improve Website Speed & Performance [2026]

Website speed is not a nice-to-have — it is a business metric. Amazon found that every 100ms of latency cost them 1% in sales. Google confirmed that page speed is a ranking factor, and sites failing Core Web Vitals get penalised in search results. For Indian websites serving users on mobile networks, speed is even more critical — 70%+ of traffic comes from mobile devices on connections that range from fast 4G to slow 3G. This guide provides actionable, step-by-step techniques to make your website measurably faster, with tools, benchmarks, and techniques you can implement today.

Step 1: Audit Your Current Performance

Before optimising, measure. You need baseline numbers to know what to fix and to verify that your changes actually improve performance.

Essential measurement tools:

• Google PageSpeed Insights: The most important tool. It measures Core Web Vitals (LCP, FID/INP, CLS) using both lab data (simulated) and field data (real user measurements from Chrome users). Scores range from 0-100. Target: 90+ on both mobile and desktop. Run it on your homepage, top landing pages, and product/service pages.
• Google Search Console (Core Web Vitals report): Shows how Google evaluates your site's performance for search rankings. It categorises URLs as Good, Needs Improvement, or Poor. Fix "Poor" URLs first — they are being penalised in search results.
• WebPageTest: Advanced tool that shows waterfall charts (what loads when and how long each resource takes), filmstrip views (visual progress of page loading), and multi-location testing. Test from Mumbai or Bangalore servers for India-relevant results.
• Lighthouse (in Chrome DevTools): Same engine as PageSpeed Insights but runs locally. Press F12 → Lighthouse tab → Run audit. Provides specific recommendations with estimated savings for each fix.
• GTmetrix: Combines PageSpeed and Web Vitals metrics with waterfall analysis. Free tier allows testing from multiple locations.

What to measure:

Metric	What It Measures	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	Time to render the largest visible element	< 2.5s	2.5-4.0s	> 4.0s
INP (Interaction to Next Paint)	Responsiveness to user interactions	< 200ms	200-500ms	> 500ms
CLS (Cumulative Layout Shift)	Visual stability (do elements jump around?)	< 0.1	0.1-0.25	> 0.25
TTFB (Time to First Byte)	Server response time	< 200ms	200-600ms	> 600ms
Total Page Size	Total bytes downloaded	< 1.5 MB	1.5-3 MB	> 3 MB

Record these numbers for your top 10 pages. This becomes your baseline for measuring improvement.

Step 2: Optimise Images

Images are the single biggest performance bottleneck on most websites. They typically account for 50-70% of total page weight. Optimising images is the fastest way to dramatically improve load times.

Image optimisation techniques:

• Use WebP format: WebP images are 25-35% smaller than JPEG at equivalent quality, and support transparency (unlike JPEG). Convert all images to WebP. Use the <picture> element to serve WebP with JPEG fallback for older browsers. In Next.js, the built-in Image component handles this automatically.
• Use AVIF for maximum compression: AVIF achieves 50% smaller file sizes than JPEG. Browser support is now at 90%+ in 2026. Use AVIF as the primary format with WebP as fallback. Next.js Image component supports AVIF natively.
• Implement responsive images: Serve different image sizes based on the user's screen. A 1920px hero image is wasted on a 375px mobile screen. Use srcset and sizes attributes to let the browser choose the right size. This alone can reduce image bytes by 60%+ on mobile.
• Lazy load below-the-fold images: Only load images when they are about to scroll into view. Use loading="lazy" attribute on img tags. This means users only download images they actually see — pages with 20 images might only load 3-4 initially.
• Compress aggressively: Most images can be compressed to 80% quality with zero visible difference. Use tools: Squoosh (manual, Google tool), Sharp (Node.js library for automated processing), TinyPNG (batch compression). For Next.js projects, the Image component with quality={80} handles this.
• Set explicit dimensions: Always include width and height attributes on images. Without them, the browser does not know how much space to reserve, causing layout shifts (CLS) when images load. In Next.js, the Image component requires width and height by design.
• Use SVG for icons and illustrations: SVGs are resolution-independent and tiny (typically 1-5KB). Replace PNG icons and simple illustrations with SVGs. Inline critical SVGs directly in the HTML to save HTTP requests.

Quick win: Run all your images through Squoosh with WebP format at 80% quality. For a typical Indian business website with 20-30 images, this alone can reduce page size by 1-3 MB and improve LCP by 1-3 seconds.

Step 3: Implement Caching and CDN

Caching stores previously generated content so it does not need to be recreated for every request. A CDN (Content Delivery Network) serves cached content from servers geographically close to users.

Browser caching:

• Set Cache-Control headers for static assets (images, CSS, JS, fonts). Recommended: Cache-Control: public, max-age=31536000, immutable for versioned assets (files with hash in the name like main.abc123.js). This tells browsers to cache for 1 year — the hash changes when the file content changes, forcing a new download.
• For HTML pages, use shorter cache times: Cache-Control: public, max-age=3600 (1 hour) or use stale-while-revalidate to serve cached content while checking for updates in the background.
• For API responses, cache where appropriate: product listings that change infrequently can be cached for 5-15 minutes, reducing server load significantly.

CDN setup:

• Cloudflare (recommended, free tier available): Cloudflare is the easiest CDN to set up — change your domain's nameservers to Cloudflare's, and your entire site is served through their global network with 300+ edge locations. The free tier includes CDN, DDoS protection, SSL, and basic caching. For Indian users, Cloudflare has edge servers in Mumbai, Chennai, and New Delhi.
• Vercel Edge Network: If your site is on Next.js deployed to Vercel, you get a global CDN automatically. Vercel's Edge Network serves static content from the closest edge location and runs Edge Functions for dynamic content close to users.
• AWS CloudFront: For sites hosted on AWS, CloudFront provides a CDN with Mumbai and Bangalore edge locations. More configuration required than Cloudflare but integrates seamlessly with S3, EC2, and Lambda.

Impact: A CDN typically reduces page load time by 40-60% for users far from your origin server. For a website hosted in Mumbai, users in Delhi experience 50-100ms less latency, and users in the US experience 200-400ms less latency with a CDN.

Step 4: Minimise JavaScript and CSS

Excessive JavaScript is the most common cause of poor Interaction to Next Paint (INP) scores. Large CSS files delay rendering. Both need aggressive optimisation.

JavaScript optimisation:

• Code splitting: Split your JavaScript into smaller chunks that load on demand. In Next.js, this happens automatically by route — each page loads only the JavaScript it needs. For other frameworks, use dynamic imports: import('module') loads the module only when needed, not at initial page load.
• Tree shaking: Modern bundlers (Webpack, Vite, Turbopack) automatically remove unused code from dependencies. But this only works with ES modules (import/export syntax). If you are importing utilities, import specific functions: import debounce from 'lodash/debounce' instead of import _ from 'lodash' (which imports the entire 70KB library).
• Defer non-critical scripts: Analytics (Google Analytics, Meta Pixel), chat widgets, and social media embeds should load after the main content. Use defer or async attributes on script tags. Load third-party scripts after the window load event. Partytown (by Builder.io) runs third-party scripts in a web worker, completely removing them from the main thread.
• Audit bundle size: Use webpack-bundle-analyzer or source-map-explorer to visualise your JavaScript bundle. Identify large dependencies and find smaller alternatives. Example: replace moment.js (300KB) with dayjs (2KB) or date-fns (tree-shakable).
• Remove unused dependencies: Run npx depcheck to find npm packages that are imported but not used. Remove them. Each unused dependency adds to build time and potentially to bundle size.

CSS optimisation:

• Use Tailwind CSS or CSS Modules: Tailwind CSS with its purge configuration removes unused CSS at build time — a typical Tailwind site ships 10-15KB of CSS instead of 200KB+. CSS Modules scope styles to components, preventing global CSS accumulation.
• Inline critical CSS: Extract the CSS needed for above-the-fold content and inline it directly in the HTML. This eliminates the render-blocking effect of external CSS files for initial paint. Tools: Critical (npm package) or critters (webpack plugin).
• Remove unused CSS: Use PurgeCSS to scan your HTML and remove CSS rules that are never applied. For WordPress sites with bloated themes, this can reduce CSS by 80-90%.

Step 5: Optimise Server Response Time

Time to First Byte (TTFB) measures how quickly your server responds. If TTFB is slow, everything else is slow — the browser cannot start rendering until it receives the first byte of HTML.

Server-side optimisation:

• Database query optimisation: Slow database queries are the most common cause of high TTFB. Add indexes to frequently queried columns. Use EXPLAIN ANALYZE to identify slow queries. Implement connection pooling. Cache frequently accessed data in Redis — a Redis lookup takes 1-5ms versus 50-200ms for a database query.
• Server-side caching: Cache rendered HTML pages for content that does not change per-user. In Next.js, use Incremental Static Regeneration (ISR) to pre-render pages and refresh them at set intervals. For dynamic pages, implement response caching with Redis — store the rendered response for 30-300 seconds depending on how frequently the content changes.
• HTTP/2 or HTTP/3: Ensure your server supports HTTP/2 (multiplexed connections, header compression) or HTTP/3 (QUIC protocol, faster on unreliable networks like mobile). Most modern hosting platforms support HTTP/2 by default. Cloudflare enables HTTP/3 with one click.
• Upgrade hosting: If your WordPress site is on ₹149/month shared hosting, TTFB will be 500ms-2 seconds. Upgrading to a ₹500-1,000/month managed WordPress host (SiteGround, Cloudways) can reduce TTFB to 200-400ms. For custom applications, ensure your server is in India (AWS Mumbai, DigitalOcean Bangalore) to minimise latency for Indian users.
• Gzip/Brotli compression: Enable server-side compression to reduce the size of HTML, CSS, and JavaScript sent over the network. Brotli provides 15-20% better compression than Gzip. Most web servers (Nginx, Apache) and CDNs (Cloudflare) support both.

Step 6: Fix Core Web Vitals Issues

Core Web Vitals are Google's specific performance metrics that affect search rankings. Fix these specifically:

Fix LCP (Largest Contentful Paint):

• Identify your LCP element — usually the hero image, main heading, or featured video. Check in Chrome DevTools → Performance tab
• Preload the LCP image: <link rel="preload" as="image" href="/hero.webp">
• Do not lazy-load the LCP image — it must load immediately, not on scroll
• Use fetchpriority="high" on the LCP image element
• Reduce server response time (TTFB affects LCP directly)
• Eliminate render-blocking resources above the fold

Fix INP (Interaction to Next Paint):

• INP measures how quickly your page responds to user interactions (clicks, taps, key presses)
• Break up long JavaScript tasks — any task over 50ms blocks the main thread. Use requestIdleCallback or scheduler.yield() to break long tasks
• Debounce input handlers (search inputs, scroll handlers)
• Use CSS animations instead of JavaScript animations where possible
• Reduce the number of DOM elements — pages with 3,000+ DOM elements are slower to interact with

Fix CLS (Cumulative Layout Shift):

• Set explicit width and height on all images and videos
• Reserve space for ads and dynamic content with min-height or aspect-ratio CSS
• Avoid inserting content above existing content after page load (e.g., consent banners, notification bars)
• Use font-display: swap for web fonts, and preload critical fonts to prevent layout shifts during font loading
• Avoid dynamically injected content that pushes existing content down

Step 7: Set Up Performance Monitoring

Performance degrades over time as content is added, dependencies are updated, and new features are built. Continuous monitoring catches regressions before they impact users and rankings.

Monitoring setup:

• Google Search Console: Monitor Core Web Vitals report weekly. Set up email alerts for performance regressions. This shows how Google sees your site's performance.
• Lighthouse CI: Run Lighthouse automatically on every deployment using GitHub Actions. Set performance budgets (fail the build if score drops below 85). This prevents performance regressions from reaching production.
• Real User Monitoring (RUM): Measure actual user experience using web-vitals JavaScript library, Vercel Analytics, or SpeedCurve. Lab tests (Lighthouse) simulate performance; RUM shows what real users experience on real devices and networks.
• Performance budgets: Set budgets for: total page size (< 1.5 MB), JavaScript bundle size (< 250 KB), number of HTTP requests (< 50), LCP (< 2.5s). Enforce these in your CI/CD pipeline.
• Weekly review: Spend 15 minutes weekly reviewing PageSpeed Insights scores for your top 10 pages. Address any page that drops below 85 immediately.

Cost and Timeline Summary

Optimisation	Impact	Effort	Cost
Image optimisation	High (40-60% size reduction)	1-2 days	₹0 (free tools)
CDN setup (Cloudflare)	High (40-60% faster globally)	1 hour	₹0 (free tier)
Browser caching headers	Medium (repeat visits 80% faster)	1-2 hours	₹0
JavaScript optimisation	High (INP improvement)	2-5 days	₹20,000-60,000 (developer time)
Server optimisation	High (TTFB reduction)	1-3 days	₹10,000-50,000
Core Web Vitals fixes	High (SEO ranking impact)	3-7 days	₹30,000-1 lakh
Complete performance overhaul	Transformative	2-4 weeks	₹50,000-3 lakh

When to DIY vs Hire a Professional

DIY optimisation works for:

• Image compression and format conversion (use Squoosh, free)
• Cloudflare CDN setup (straightforward DNS change)
• Installing caching plugins (WP Super Cache, W3 Total Cache for WordPress)
• Basic lazy loading (add loading="lazy" to images)
• Removing unused plugins and themes

Hire a professional when:

• Your PageSpeed score is below 50 and you do not know what is causing the problem
• Core Web Vitals are failing in Google Search Console and affecting your rankings
• JavaScript bundle analysis and code splitting require framework expertise
• Database query optimisation and server-side caching need backend engineering knowledge
• You want a systematic performance overhaul rather than piecemeal fixes

JK Tech Hub provides website performance optimisation services. We audit your site, identify the highest-impact fixes, implement them, and set up monitoring to prevent regressions. Our clients typically see 40-70% improvement in PageSpeed scores and measurable improvements in search rankings within 2-4 weeks. Get a free performance audit.

Related Resources

• Web Development Services
• SEO Services
• How to Build a Website for Your Business
• Best Cloud Hosting in India 2026
• Development Cost Calculator

Sources & References

• Google — Web Vitals: Essential Metrics for Healthy Sites
• Google — PageSpeed Insights API Documentation
• HTTP Archive — State of the Web Report 2026

Is your website too slow? Contact JK Tech Hub for a free performance audit. We optimise websites for speed, Core Web Vitals, and SEO — 150+ projects delivered, 4.9/5 client rating, based in Rajkot, Gujarat. Get an instant estimate.