Website speed is not a nice-to-have. It is one of the most direct levers you have over your search rankings, your conversion rate, and whether visitors stay or leave. Google has used page speed as a ranking factor since 2010 for desktop and 2018 for mobile. Studies consistently show that a one-second delay in load time reduces conversions by 7% and increases bounce rates significantly. Amazon calculated that every 100 milliseconds of latency costs them 1% in sales.

The good news: most websites are slow because of fixable problems, and the fixes range from five-minute configuration changes to hosting upgrades that pay for themselves almost immediately. This guide covers every layer of website performance — from the hosting infrastructure at the bottom to the code and images at the top — ranked by how much impact each fix actually delivers.

Start with your hosting. It’s the foundation everything else sits on, and the most commonly overlooked variable in site speed. A fast host with a well-optimized site is genuinely fast. A slow host with a perfectly optimized site is still slow — because there’s a ceiling on what optimization can overcome.

1. Why Website Speed Matters

Speed affects three things that matter enormously to any website: how Google ranks it, how visitors behave on it, and how much revenue it generates. These aren’t abstract concerns — they’re measurable and the data is consistent across industries.

Speed and Search Rankings

Google’s Core Web Vitals — a set of real-world performance metrics measuring loading speed, interactivity, and visual stability — are confirmed ranking signals. Slow pages don’t just frustrate visitors; they rank lower in search results, which means less traffic to be frustrated in the first place. Google’s own research found that as page load time goes from one second to ten seconds, the probability of a mobile visitor bouncing increases by 123%.

Critically, Google measures real user experience via field data collected from Chrome users, not just lab-based speed scores. A site that looks fast in a testing tool but loads slowly for real users on real networks will still be penalized. This makes genuine hosting performance — not just optimization tricks — more important than ever.

Speed and User Behavior

Visitors are impatient in ways that are easy to underestimate. Research by Google found that 53% of mobile users abandon a site that takes more than three seconds to load. That means a site loading in four seconds loses more than half its mobile visitors before they see a single word of content. Three seconds isn’t a long time — until you’re waiting for a website, and then it’s an eternity.

Even sub-second differences matter for engaged visitors. Studies by Akamai and others consistently show that 100–200ms improvements in response time produce measurable increases in pages per session and conversion rates. Users don’t consciously notice small speed improvements — but their behavior changes anyway.

Speed and Revenue

For e-commerce sites, the revenue impact of speed is well-documented and significant. Walmart found that for every one-second improvement in page load time, conversions increased by 2%. Mozilla saw a 15.4% increase in downloads after speeding up their pages by 2.2 seconds. Portent’s research found that a site loading in one second had a 39% higher conversion rate than the same site loading in five seconds. The relationship is consistent: faster equals more money.

2. How Hosting Affects Speed

Your hosting infrastructure sets the ceiling for your site’s performance. No amount of optimization can make a slow server fast. Understanding exactly how hosting contributes to speed helps you identify the right upgrade when optimization alone isn’t enough.

Time to First Byte (TTFB)

TTFB measures how long it takes for a visitor’s browser to receive the very first byte of response from your server after making a request. It’s the most direct measure of raw server performance — before the browser has done anything with the response at all. A high TTFB means the server is slow to respond, and everything that happens after it (parsing HTML, loading CSS, fetching images) is delayed accordingly.

TTFB is almost entirely determined by your hosting environment. A fast server on a fast network with properly configured software returns a TTFB under 200ms. An overloaded shared host can return TTFB of 1,000–3,000ms — meaning a full one to three seconds pass before the browser can even begin loading your page. No caching plugin or image compression can fix that.

Server Hardware

NVMe SSD storage is significantly faster than standard SSD, and both are dramatically faster than the spinning hard drives that some budget hosts still use. Disk read speed affects every database query and file read your site performs. A host using NVMe storage processes these operations many times faster than one using older hardware, and it shows directly in load times.

CPU and RAM determine how quickly the server can execute PHP, run database queries, and handle concurrent requests. Shared hosting limits both — you share a fixed pool with hundreds of other sites. A traffic spike on one site can starve resources for all its neighbors.

Server Software Stack

The web server software handling requests matters. LiteSpeed, used by many performance-focused hosts, is significantly faster than Apache for dynamic PHP content — particularly for WordPress. Nginx is faster than Apache for serving static files and handling concurrent connections. PHP version also matters: PHP 8.x is substantially faster than PHP 7.4, which was already faster than PHP 7.0. Running an outdated PHP version on a new server still costs you speed.

Server Location

Physical distance between your server and your visitor adds latency that cannot be eliminated through optimization. Data has to travel at the speed of light through fiber optic cables — and a server on the wrong continent adds hundreds of milliseconds to every request, every time. This is why CDNs exist, and why server location matters for audiences you can’t serve through a CDN effectively.

Resource Allocation Model

Shared hosting pools resources across hundreds of sites. VPS hosting gives you a guaranteed slice. Cloud hosting provisions resources dynamically and can scale up instantly. These different models have radically different performance profiles under load. A shared host running at 60% capacity feels fine. The same host at 95% capacity on a busy afternoon feels like a different product entirely.

The chart above reflects a consistent finding in performance work: most of the impact is concentrated in a few areas. Fixing your hosting tier and getting caching right will do more for your speed than any number of incremental code tweaks. Start at the top and work down.

3. Choosing the Right Hosting for Speed

Not all hosting is equally fast, and the differences are large enough to matter significantly. Here’s how each hosting type compares on performance, and what to look for within each tier.

Shared Hosting: Manageable, With the Right Provider

Shared hosting is the most performance-variable category — the gap between the fastest and slowest shared hosts is enormous. A well-run shared host on LiteSpeed servers with NVMe storage and proper resource limits can deliver TTFB under 300ms for a lightly trafficked site. A poorly managed shared host on aging Apache servers with hard drives can deliver TTFB of 1,500ms+ on a bad afternoon.

If you’re on shared hosting and speed matters to you, provider choice is everything. Look specifically for:

• LiteSpeed web server (substantially faster than Apache for WordPress and PHP sites)
• NVMe SSD storage mentioned in the plan specs
• PHP 8.2 or 8.3 available and selectable in the control panel
• HTTP/2 or HTTP/3 support (speeds up parallel asset loading)
• Independent third-party speed test data from review sites — not just the host’s own claims

VPS Hosting: Consistent and Configurable

A VPS eliminates the “noisy neighbor” problem that makes shared hosting performance unpredictable. Your allocated CPU and RAM are yours — traffic spikes from other tenants on the same physical machine don’t affect you. For sites that have grown beyond shared hosting or need consistent performance, a VPS is almost always a meaningful upgrade. The trade-off is more configuration responsibility — you’ll need to manage your server stack or choose a managed VPS product.

Managed WordPress Hosting: The Speed-Optimized Option

Hosts like Kinsta, WP Engine, and Cloudways build their entire infrastructure around WordPress performance. Their stacks are tuned specifically for WordPress: PHP-FPM for process management, Redis or Memcached for object caching, Nginx for fast static file serving, and enterprise CDN integration baked in. They run independent tests that consistently put these hosts at the top of TTFB and load time benchmarks.

The premium is real — these hosts cost more than shared hosting — but the performance difference is also real and measurable. For any WordPress site where speed meaningfully affects revenue, the math usually favors managed WordPress hosting by a comfortable margin.

Cloud Hosting: Scalable and Globally Distributed

Cloud platforms (AWS, Google Cloud, DigitalOcean, Vultr) allow you to place servers geographically close to your audience, scale resources up instantly under load, and combine with CDNs for global distribution. For high-traffic sites or applications with global audiences, cloud infrastructure offers a performance ceiling that other hosting types can’t match. The trade-off is greater complexity in setup and management.

4. Server Location & CDNs

Speed of light is not a metaphor — it’s a literal constraint on how fast your website can respond to a visitor. A server in New York responding to a visitor in Sydney has to send data roughly 16,000km each way. At the speed of light through fiber, that round trip takes a minimum of around 170ms — before the server does anything at all. Serving that same visitor from a Sydney CDN edge node reduces that latency to under 10ms.

Choosing the Right Server Location

If your audience is concentrated in a single region, host your origin server there. A UK business whose customers are overwhelmingly in the UK should use a UK data center, not a US one. Many hosting providers offer data center location choices during signup — always pick the one closest to the majority of your audience.

If your audience is global, no single server location is optimal for everyone. That’s where CDNs become essential.

What a CDN Does

A Content Delivery Network (CDN) is a globally distributed network of servers — called edge nodes or PoPs (Points of Presence) — positioned in data centers around the world. When a visitor requests your site, the CDN serves static assets (images, CSS, JavaScript, fonts) from the edge node geographically closest to them rather than from your origin server. A visitor in Tokyo gets content from a Tokyo edge node. A visitor in São Paulo gets it from São Paulo. Your origin server only handles requests for dynamic content that can’t be cached.

For most sites, 70–90% of page weight consists of static assets that can be CDN-cached. Moving that content delivery to edge nodes near each visitor dramatically reduces the distance data travels, cutting load times for international visitors by hundreds of milliseconds.

Cloudflare: The Default Starting Point

For most websites, Cloudflare’s free plan is the right first CDN. It operates one of the largest CDN networks in the world, with edge nodes in over 300 cities. Setup is as simple as changing your domain’s nameservers to Cloudflare’s — after which Cloudflare automatically caches static assets, adds DDoS protection, enables HTTP/3, and provides a suite of performance optimizations including automatic image compression and minification.

Cloudflare’s free tier delivers genuine, measurable speed improvements for most websites. Their paid plans add more aggressive caching, image resizing, and performance features — but for the majority of sites, free is more than sufficient as a starting point.

CDN Caching Behavior

CDNs cache static content automatically based on HTTP cache headers your server sends. Understanding this helps you configure caching correctly:

• Files with long cache TTLs (CSS, JS, images with versioned filenames) should be cached aggressively — 30 days or more
• HTML pages should generally not be cached by the CDN, or cached with very short TTLs, since they contain dynamic content that changes
• After publishing new content or deploying a site update, purge the CDN cache to ensure visitors get fresh content immediately

5. Caching: The Biggest Single Win

Caching is the practice of storing a pre-generated version of content so it can be served instantly without repeating the work of generating it from scratch. For a dynamic site — one that queries a database and assembles HTML for every visitor — caching is the single most impactful optimization available. The difference between a cached and uncached WordPress page is typically 10x to 50x in response time.

Understanding the Cache Stack

There are multiple caching layers in a modern web stack, and they compound. Getting all of them working together is where serious performance gains come from:

Browser Cache

The visitor’s own browser stores copies of assets it has already downloaded. When they return to your site, images, CSS, and JavaScript are loaded from the local disk instead of re-downloaded. Set appropriate Cache-Control headers — long TTLs for static assets that rarely change, shorter TTLs for content that updates frequently. Most caching plugins handle this automatically.

Page Cache

Page caching stores a fully-rendered HTML copy of each page. When the next visitor requests that page, the server returns the stored HTML instantly — no PHP execution, no database queries, no template rendering. For a standard shared host, serving a cached page can be 20–100x faster than generating it dynamically. This is the most important cache layer for WordPress and other CMS platforms.

Object Cache

Object caching stores the results of expensive database queries in memory (RAM) so they can be retrieved instantly on repeat requests without hitting the database again. Redis and Memcached are the standard tools. Most managed WordPress hosts include Redis object caching. On self-managed hosting, it requires a plugin and server-side setup but delivers meaningful speed improvements on database-heavy sites.

Opcode Cache

PHP compiles your code into bytecode every time a page is requested — unless opcode caching is enabled, which stores the compiled bytecode in memory. OPcache (built into PHP 5.5+) is usually enabled by default on modern hosts and makes PHP execution significantly faster at essentially zero cost. Verify it’s enabled on your host; if it’s not, enabling it is a configuration change that takes 60 seconds.

Caching Plugins for WordPress

The right caching plugin depends on your host and server setup:

6. Image Optimization

Images are typically the largest component of a web page by file size — often 50–80% of total page weight. Unoptimized images are the most common cause of slow pages on otherwise well-configured sites. The good news: image optimization is largely automatable, and the gains are often dramatic.

Use the Right Format

WebP is the modern standard for web images. It delivers equivalent visual quality to JPEG at roughly 25–35% smaller file sizes, and better quality than PNG at significantly smaller sizes. All major browsers have supported WebP since 2020. If you’re still serving JPEG and PNG images without a WebP conversion strategy, you’re sending visitors unnecessarily large files on every page load.

AVIF is the next-generation format — even smaller than WebP — but browser support, while growing, is not universal enough to rely on as a primary format in 2026. The right approach is to serve AVIF to browsers that support it and WebP as a fallback, using the HTML <picture> element or an image optimization CDN that handles format negotiation automatically.

Compress Before Uploading

Don’t upload a 4MB DSLR photo and rely on CSS to display it at 800px wide — the browser still downloads all 4MB. Resize images to their actual display dimensions before uploading. A hero image displayed at 1200px wide should be 1200px wide in the file. Use a tool like Squoosh (free, browser-based) or ImageOptim (Mac) to compress images before upload.

Lazy Loading

Lazy loading defers loading of images below the fold until the visitor scrolls near them. This means the initial page load only fetches images the visitor actually sees immediately — everything else loads on demand. The result is faster initial page load times and reduced bandwidth. Modern browsers support native lazy loading via the loading="lazy" HTML attribute — no JavaScript required. Add it to every image that isn’t in the above-the-fold viewport.

Responsive Images

Serving a 2400px image to a mobile visitor with a 375px screen is wasteful. The srcset attribute lets you provide multiple image sizes and lets the browser choose the most appropriate one for the device and screen density. Most image optimization plugins handle this automatically, but it’s worth verifying that your theme and page builder aren’t bypassing the mechanism.

Image Optimization Plugins and CDNs

For WordPress sites, plugins that automate the entire image optimization pipeline — compression, WebP conversion, lazy loading, and responsive image generation — are worth the investment. ShortPixel (paid, very affordable), Imagify (paid), and Smush (free with limitations) are the most widely used. Cloudflare’s image optimization features (Polish and Mirage) handle compression and WebP conversion at the CDN level for sites using Cloudflare — making plugins redundant for that function.

7. Core Web Vitals Explained

Google’s Core Web Vitals are three specific metrics that measure real user experience. They’re the performance signals that feed directly into Google’s ranking algorithm, and understanding them tells you exactly where to focus optimization effort.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page — typically a hero image, video poster, or large text block — to fully load and render. It’s Google’s primary measure of perceived loading speed from the user’s perspective.

• Good: Under 2.5 seconds
• Needs improvement: 2.5–4 seconds
• Poor: Over 4 seconds

The biggest LCP killers: slow server response (high TTFB), render-blocking CSS or JavaScript that delays page rendering, and unoptimized hero images. Fix your hosting TTFB first, then address image optimization for the LCP element specifically.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in 2024. It measures the responsiveness of a page to user interactions — clicks, taps, keyboard input. A poor INP means the page feels sluggish and unresponsive even after it’s loaded.

• Good: Under 200ms
• Needs improvement: 200–500ms
• Poor: Over 500ms

INP is most commonly degraded by heavy JavaScript execution — particularly third-party scripts (ads, analytics, chat widgets, social embeds) that compete for the browser’s main thread. Auditing and removing unnecessary third-party scripts is the most effective INP improvement for most sites.

Cumulative Layout Shift (CLS)

CLS measures visual stability — how much page elements move around unexpectedly as the page loads. A banner that pops in and shifts all content down, images without defined dimensions that cause layout reflow, or web fonts that cause text to jump on load — all of these contribute to CLS.

• Good: Under 0.1
• Needs improvement: 0.1–0.25
• Poor: Over 0.25

Fix CLS by always defining explicit width and height attributes on images and iframes, avoiding dynamic content insertion above existing content, and using font-display: swap to handle web font loading gracefully.

8. WordPress Speed Optimization

WordPress powers a large share of the web, and it has a complicated relationship with performance. Out of the box, WordPress is not especially fast — it’s a dynamic PHP application that queries a database on every page load. But a well-optimized WordPress site can be genuinely fast. The gap between a poorly optimized and well-optimized WordPress site is larger than for almost any other platform.

PHP Version: Update It Now

PHP 8.2 and 8.3 are dramatically faster than PHP 7.4. The JIT (Just-In-Time) compiler introduced in PHP 8.0 alone delivers 10–15% speed improvements on typical WordPress workloads. Updating PHP costs nothing and takes two minutes in cPanel. Check your current PHP version in cPanel → Software → PHP Version. If you’re not on PHP 8.1 or higher, update immediately — after first verifying your theme and plugins are compatible, which they almost certainly are if they’ve been updated within the past two years.

Choose a Lightweight Theme

A bloated theme that loads dozens of CSS files, heavy JavaScript frameworks, and unnecessary font packages sets a performance ceiling before a single plugin is added. Themes built on frameworks like Divi, Avada, or WPBakery carry substantial overhead that no caching plugin fully overcomes. Lightweight, performance-focused themes — GeneratePress, Kadence, Blocksy, and Astra — load a fraction of the CSS and JavaScript of heavier alternatives and provide a much better foundation for a fast site.

Audit and Reduce Plugins

Each active plugin adds PHP execution, database queries, and often JavaScript and CSS to every page load. Fifty plugins on a WordPress site is not unusual — and it’s almost always too many. Audit your plugins ruthlessly:

• Deactivate and delete any plugin you haven’t actively used in the past six months
• Replace multi-purpose heavy plugins with lightweight alternatives that do only what you need
• Check whether your theme or page builder already includes functionality you’ve added via plugin (search, sliders, social sharing)
• Use Query Monitor (free plugin) to identify which plugins are generating the most database queries on each page

Disable WordPress Features You Don’t Use

WordPress loads several features by default that many sites don’t need — and disabling them reduces server overhead on every request:

• Heartbeat API — A background AJAX polling mechanism used for autosave and post lock notifications. On high-traffic sites, the Heartbeat API generates significant server load. Throttle or disable it using WP Rocket or the Heartbeat Control plugin.
• Emojis script — WordPress loads a JavaScript file for emoji support on every page. Most themes handle emojis via CSS. Disable it via a plugin or a few lines in functions.php.
• Embeds — WordPress automatically makes every post URL embeddable. If you don’t need this feature, disabling it removes a DNS prefetch and JavaScript file from every page.
• XML-RPC — An older remote publishing API that’s a common attack vector. If you don’t use apps that connect via XML-RPC (most people don’t), disable it entirely.

Use a Page Builder Wisely

Elementor, Divi, and similar visual page builders are convenient but add JavaScript and CSS overhead. If you’re using a page builder, make sure its asset loading is optimized — most modern page builders can be configured to load their CSS and JavaScript only on pages where they’re actually used, rather than globally on every page. This is usually in the builder’s performance settings and is consistently one of the most impactful configuration changes available to page builder users.

9. Code & Asset Optimization

After hosting, caching, and images, the next layer of optimization is the CSS, JavaScript, and HTML that your site sends to browsers. These optimizations compound — each one reduces the amount of work the browser has to do before displaying your page.

Minification

Minification removes all whitespace, comments, and unnecessary characters from CSS, JavaScript, and HTML files. A minified file is functionally identical to the original but smaller — typically 20–30% smaller for CSS and JavaScript. Every major caching plugin includes minification as a configurable option. Enable it, test that the site still renders correctly (occasionally a minifier breaks complex JavaScript), and leave it on.

Combining Files

Reducing the number of individual HTTP requests a page makes speeds up load time, particularly for visitors on high-latency connections. Combining multiple CSS files into one, and multiple JavaScript files into one, reduces round trips. Note: with HTTP/2 and HTTP/3, the benefit of file combining is reduced (the protocols handle parallel requests efficiently), but it still helps on older connections and for reducing processing overhead.

Defer and Async JavaScript Loading

By default, JavaScript in the <head> of an HTML document blocks the browser from rendering the page until the script is downloaded and executed — even if the script has nothing to do with what the visitor sees immediately. Adding the defer attribute tells the browser to download the script in the background and execute it after the HTML is parsed. The async attribute downloads and executes it immediately but without blocking. Use defer for most scripts; use async for analytics and other scripts that don’t depend on the DOM. Most caching plugins handle this automatically.

Remove Render-Blocking Resources

Render-blocking resources are CSS or JavaScript files that the browser must download and process before it can display anything on the page. Identifying and eliminating unnecessary render-blocking resources is one of the most reliable ways to improve LCP scores. Google PageSpeed Insights flags these explicitly — address the ones it identifies, prioritizing the highest-impact items.

Preload Critical Resources

The <link rel="preload"> HTML tag tells the browser to fetch specific resources — typically the LCP image, the main font file, or a critical CSS file — at the highest priority, before it would normally encounter them in the HTML. For a hero image that defines your LCP score, adding a preload hint can reduce LCP by several hundred milliseconds on its own. Most modern caching and performance plugins include preload configuration for fonts and images.

Eliminate Unnecessary Third-Party Scripts

Every third-party script — ad network, analytics tool, social sharing button, live chat widget, retargeting pixel — makes an external network request, adds JavaScript to execute on the main thread, and introduces a dependency on a server you don’t control. Audit your third-party scripts the same way you audit plugins: remove anything that isn’t earning its keep. A site with five essential third-party scripts loads faster and scores better on INP than the same site with fifteen.

10. Database Optimization

For dynamic sites, the database is the engine behind every page load. A bloated, poorly indexed database adds latency to every request. Regular maintenance keeps query times low and the site snappy.

Clean Up WordPress Database Bloat

WordPress accumulates database overhead over time: post revisions, trashed items, spam comments, expired transients, and orphaned metadata from deleted plugins. None of this data is useful, and a database table carrying thousands of abandoned rows takes longer to query. Clean it up with WP-Optimize (free) or Advanced Database Cleaner. Schedule automatic weekly cleanups to keep the database lean going forward.

Limit Post Revisions

WordPress saves a revision every time you save a post. On a site with years of content and active editing, this creates thousands of revision rows in the database. Add this line to wp-config.php to limit revisions to three per post: define('WP_POST_REVISIONS', 3);. Then run a one-time cleanup to remove existing excess revisions.

Use Object Caching to Reduce Database Load

As covered in the caching section, Redis or Memcached object caching stores frequently-used query results in memory. On a site with heavy database usage — WooCommerce stores, membership sites, news sites with complex queries — object caching can reduce database load by 50–80%, directly improving response times. Check whether your host supports Redis (most managed WordPress hosts do; many VPS providers do; most shared hosts don’t).

Optimize Database Tables

MySQL tables fragment over time as rows are added, updated, and deleted. Running OPTIMIZE TABLE on WordPress tables periodically defragments them and reclaims unused space. WP-Optimize does this automatically, or you can run it manually via phpMyAdmin. On very active sites, this optimization makes a measurable difference in query performance.

11. How to Measure Your Speed

You can’t improve what you don’t measure. Here are the tools that matter, and how to use them correctly.

Google PageSpeed Insights

The most important speed tool for SEO purposes, because it uses the same Lighthouse engine Google uses internally. Run both the mobile and desktop tests — mobile is what Google’s algorithm primarily evaluates. PageSpeed Insights shows both lab data (synthetic test) and field data (real user measurements from Chrome users). Pay more attention to the field data for SEO purposes; pay attention to the lab data for optimization guidance, since it gives you specific, actionable recommendations.

Google Search Console — Core Web Vitals Report

Search Console shows your real-world Core Web Vitals data aggregated across all pages that have sufficient traffic to generate field data. This is the authoritative source for understanding how Google sees your site’s performance. Check it monthly. Pages flagged as “Poor” in the Core Web Vitals report are the highest-priority items to address.

GTmetrix

GTmetrix provides detailed waterfall charts showing exactly which resources load in what order and how long each takes. Invaluable for diagnosing specific bottlenecks — particularly render-blocking resources, slow third-party scripts, and oversized images. Run tests from a server location close to your primary audience for the most representative results.

WebPageTest

The most powerful free speed testing tool available. WebPageTest allows you to test from specific geographic locations and on specific device and connection configurations — including throttled mobile connections that reflect real-world conditions far better than a fiber desktop test. Use WebPageTest when you need deep diagnostic detail or want to measure how your site performs for users on slow mobile networks.

Establishing a Baseline and Measuring Progress

Before making any optimization changes, record your current scores across all three tools. Document LCP, INP, CLS, and total page load time. Then implement one optimization at a time and re-test — this is the only reliable way to know what’s actually working. Implementing five changes at once and seeing a 30% improvement tells you the changes collectively helped; it doesn’t tell you which ones drove the gain or whether any of them hurt.

12. Speed Optimization Checklist

Work through this from top to bottom. Items at the top deliver the most impact — don’t spend hours on low-impact tweaks before addressing the fundamentals.

Hosting Foundation

• Verify your host uses NVMe SSD storage and a modern web server (LiteSpeed or Nginx preferred)
• Confirm PHP 8.1 or higher is available and set that version for your site in cPanel
• Confirm HTTP/2 or HTTP/3 is enabled on your hosting account
• Check OPcache is enabled (ask your host or check phpinfo())
• Test your server’s raw TTFB using GTmetrix or WebPageTest — target under 500ms
• If TTFB consistently exceeds 800ms, evaluate upgrading to a faster host or hosting tier

CDN and Network

• Set up Cloudflare (free plan) if not already in place
• Enable Cloudflare’s Auto Minify for CSS, JS, and HTML
• Enable Cloudflare’s Polish (image compression) if on a paid plan
• Verify static assets are being served from CDN edge nodes (check response headers for CF-Cache-Status: HIT)
• Configure long cache TTLs for static assets (CSS, JS, images)

Caching

• Install and configure a caching plugin appropriate to your host (or use server-level cache if provided)
• Enable page caching for all cacheable pages
• Enable browser caching headers for static assets
• Enable Redis or Memcached object caching if your host supports it
• Verify the site functions correctly with cache enabled (test logged-in and logged-out states separately)

Images

• Install an image optimization plugin or use Cloudflare’s image compression
• Enable WebP conversion for all images
• Add loading=”lazy” to all images below the fold
• Ensure the LCP image (hero image) is NOT lazy-loaded — it should load immediately
• Add a preload hint for the LCP image in the page head
• Verify all images have explicit width and height attributes set (prevents CLS)

Code and Assets

• Enable CSS and JavaScript minification in your caching plugin
• Defer non-critical JavaScript loading
• Identify and remove or replace render-blocking resources flagged by PageSpeed Insights
• Audit third-party scripts — remove any that aren’t actively contributing to business goals
• Configure page builder (if used) to load assets only on pages where they’re needed

Database (WordPress)

• Run a database cleanup to remove post revisions, transients, spam, and orphaned metadata
• Set WP_POST_REVISIONS to 3 or fewer in wp-config.php
• Run OPTIMIZE TABLE on all WordPress tables
• Schedule automatic weekly database maintenance

Measure and Verify

• Record baseline scores in PageSpeed Insights, GTmetrix, and WebPageTest before starting
• Re-test after each significant change to measure individual impact
• Check Google Search Console Core Web Vitals report monthly
• Target: LCP under 2.5s, INP under 200ms, CLS under 0.1 in field data