Speed Up a WordPress Site in 2027: A Beginner’s Plan

web.dev defines three Core Web Vitals with “good” targets. Largest Contentful Paint (LCP), which measures loading, should happen within 2.5 seconds of when the page first starts loading. Interaction to Next Paint (INP), which measures how fast the page responds to a tap or click, should be 200 milliseconds or less. Cumulative Layout Shift (CLS), which measures how much the page jumps around, should be 0.1 or less.

web.dev also says a page passes when it meets the targets at the 75th percentile for all three metrics. In plain words, three out of four visits should be good, not just your fast laptop on office Wi-Fi. Want the full explanation? Read Core Web Vitals for WordPress.

My honest view: speed is a tiebreaker and a customer-experience issue, not a magic ranking lever. Fix what is clearly slow, then spend your time on content. Anyone who promises a ranking jump from a speed plugin has not read the docs.

Step 1: Measure Before You Touch Anything

Test your home page and two other important pages with a speed testing tool such as PageSpeed Insights, and write the LCP, INP, and CLS down with the date. Test on mobile too, since most visitors use phones. This sheet is your proof that a change worked. Also back up the site, so you can undo anything.

Step 2: Add Page Caching

Caching saves a ready-made copy of each page so WordPress does not rebuild it for every visitor. WordPress says caching plugins cache your posts and pages as static files. Install one reputable caching plugin, not three. Also set browser caching headers such as Cache-Control, so returning visitors reuse files they already downloaded. If your host offers a persistent object cache, WordPress says it reduces trips to the database. Ask your host.

Step 3: Fix Your Images

Images are usually the heaviest part of a page. Resize them to the size you actually display, compress them, and consider WebP, a format WordPress’s guide describes as smaller. Add width and height attributes to every image tag, because web.dev says leaving them out increases an image’s impact on layout shift.

Use lazy loading carefully. web.dev advises loading="lazy" only for images outside the first screen, and says never lazy-load your LCP image, because it always causes unnecessary load delay. For the likely LCP image, set fetchpriority="high", but on only one or two images.

Step 4: Remove Plugins You Do Not Need

Deactivate and delete anything unused. WordPress calls this a significant way to improve performance. Then ask the same question about each remaining plugin: does it earn its weight? If one plugin slows the site, check its documentation, ask its support forum, or switch to a similar one. Test after each removal.

Step 5: Keep PHP and Your Theme Current

The WordPress guide says newer PHP versions usually include better performance optimization, and suggests an opcode cache such as OPcache. Most hosts let you switch PHP versions in the control panel. Test on a copy first, because old plugins can break. It also says a fast, lightweight theme performs much more efficiently than a heavy graphic-laden one.

Step 6: Look at Your Hosting

If the first byte takes too long, the problem is on the server, not in the page. web.dev’s LCP guide says time to first byte should take about 40% of the LCP time in an ideal split. WordPress notes that more CPU and RAM, or SSD and NVMe storage, can make a big difference. Cheap shared plans sometimes cost more in lost visitors than they save in fees. A CDN can help too, and WordPress says it works best alongside a caching plugin.

Step 7: Tidy the Database Last

WordPress suggests telling it to minimize the number of revisions saved, and keeping autoloaded options under roughly 800 KB. This is real, but it is the small stuff. Do it after the big wins, with a backup in hand.

Stacking caching plugins. Two or three cache plugins fight each other and can break pages. Fix: keep one, and read its setup notes.

Lazy-loading the hero image. It delays the very thing Google measures. web.dev says never lazy-load your LCP image. Fix: exclude the first image from lazy loading and give it high fetch priority.

Images without dimensions. The page jumps as images appear. Fix: add width and height to every image, so the browser reserves the space.

Installing a plugin to fix a plugin problem. A new plugin adds weight. Fix: remove first, add only when needed. (Yes, “optimization plugin to speed up my other plugins” is a real thing people buy.)

Never measuring. You cannot tell what worked. Fix: log LCP, INP, and CLS before and after each change, on mobile.

// my opinion, built on web.dev and WordPress documentation.

Test several times, because single runs vary. web.dev measures at the 75th percentile of real visits, so lab tests are a guide and not the verdict. Then browse the site yourself on a phone, and check that forms, menus, and checkout still work, since caching can occasionally break dynamic parts.

Real-visitor results can take a while to improve, because they reflect many visits over time. Be patient, and keep the baseline sheet. If you want a hands-on helper, I am a WordPress developer as well as an SEO, so speed fixes are routine for me. See WordPress SEO services, technical SEO, and the free SEO checker. My home page explains my cheap SEO expert rates, from €25 an hour.

• web.dev: Web Vitals (LCP, INP, CLS thresholds, 75th percentile)
• web.dev: Optimize Largest Contentful Paint (time to first byte share, fetchpriority, never lazy-load the LCP image)
• web.dev: Browser-level image lazy-loading (lazy only below the fold, width and height)
• WordPress Developer Resources: Optimization (caching, plugins, images, PHP, hosting, theme, database, CDN)

// last checked 11 Nov 2026. The order of steps and the example numbers are my own and labelled as such.