Performance & Caching

WordPress Intermediate/Advanced

Chapter 9 · Performance & Caching

WordPress Fundamentals 6 named caching plugins as an essential category without explaining why they matter so much specifically for WordPress. This chapter explains exactly that — and maps every technique directly onto Performance & Core Web Vitals's own LCP, INP, and CLS metrics, rather than treating "performance" as one vague, undifferentiated goal.

Why WordPress Specifically Has a Performance Problem

Per WordPress Fundamentals 1's own LAMP-stack material, every WordPress page load, by default, involves real PHP execution and real MySQL queries — WordPress rebuilds the page dynamically on every single request unless something intervenes. A static HTML file requires none of this; a default WordPress page genuinely does, every time, for every visitor.

Page Caching — The Single Biggest Lever

Page caching stores the fully-rendered HTML output of a page after its first generation, then serves that static copy directly for subsequent requests — skipping PHP execution and MySQL queries entirely for every visitor after the first.

Directly targets LCP

Server response time is a direct, measured contributor to Largest Contentful Paint — the slower the server takes to generate a page, the later the largest visible element can possibly appear. Skipping PHP/MySQL execution via page caching is one of the most reliable, highest-impact ways to improve LCP on a WordPress site specifically.

The classic hard problem: cache invalidation

A cached page has to be regenerated or cleared the moment its underlying content actually changes — a new comment, an edited post. A caching setup that doesn't correctly invalidate stale pages will confidently serve outdated content indefinitely, with no visible error anywhere.

Object Caching — A Different, Complementary Layer

Page caching mostly benefits anonymous, logged-out visitors — logged-in users often see personalized dashboard content that can't be cached wholesale the same way. Object caching solves a related but different problem: caching the results of individual, expensive database queries in memory, so the same query run repeatedly across many requests doesn't have to hit MySQL every single time.

Persistent vs. non-persistent

WordPress ships with a basic, built-in object cache — but it's non-persistent, meaning it only lasts for the duration of a single page request and provides no benefit across separate requests. A genuinely persistent object cache (commonly backed by Redis or Memcached) is what actually delivers repeated-query savings across many different visitors and requests over time.

Image Optimization — Also Mostly an LCP Story

The largest visible element on a page is very often an image — a hero image, a featured post image — making image handling directly relevant to LCP as well.

Lazy loading — deferring images below the initial viewport until they're actually needed, via the native loading="lazy" attribute
Responsive images — serving an appropriately-sized image per device, using the srcset attribute WordPress automatically generates from the multiple image sizes WordPress Fundamentals 7 already covered
Compression — reducing file size without materially harming visual quality, often handled by a dedicated plugin

CLS — A WordPress-Specific Risk Worth Naming

Missing width/height attributes

WordPress automatically outputs explicit width and height attributes on images in most standard contexts — a real, built-in CLS protection, since the browser can reserve the correct space before the image finishes loading. A common mistake in custom theme development is stripping these attributes out (often unintentionally, through custom image-output code), reintroducing the exact layout-shift risk WordPress's own defaults were already preventing.

INP — A Lighter Touch, Tying Back to Chapter 7

Unnecessary or poorly-optimized JavaScript execution is the primary driver of poor INP. WordPress Intermediate/Advanced 7's own proper enqueuing material — loading scripts in the footer, only enqueuing what a specific page actually needs — is directly relevant here; INP isn't a separate new problem so much as a real-world payoff of getting Chapter 7's own material right.

Mapping Techniques to Metrics

Technique	Primarily helps
Page caching	LCP (server response time)
Object caching	LCP, indirectly, for dynamic/logged-in content page caching can't cover
Lazy loading, responsive images, compression	LCP
Preserving width/height on images	CLS
Proper script enqueuing (Chapter 7)	INP

Hands-On Exercises

Exercise 1

A site enables page caching, but visitors keep seeing an old version of a post for hours after it was edited. Explain what's most likely wrong, using this chapter's own material.

📄 View solution

Exercise 2

Explain why page caching alone doesn't solve performance for logged-in users, and what a persistent object cache adds that WordPress's own built-in object cache doesn't.

📄 View solution

Exercise 3

A custom theme's own image-output code strips out the width and height attributes WordPress normally adds automatically. Explain which specific Core Web Vitals metric this most directly harms, and why.

📄 View solution

Chapter 9 Quick Reference

WordPress rebuilds pages dynamically via PHP/MySQL on every request by default, unlike a static file
Page caching — the single biggest LCP lever, skipping PHP/MySQL entirely on repeat requests; cache invalidation is the classic hard problem
Object caching — caches individual query results, benefits logged-in/dynamic content page caching can't cover; needs a persistent backend (Redis/Memcached) to help across requests
Lazy loading, responsive srcset images, and compression are all primarily LCP techniques
Missing width/height attributes on images is a real, WordPress-specific CLS risk
Proper script enqueuing (Chapter 7) is directly what improves INP
Next chapter: Capstone — Building a Custom Theme With a Custom Post Type