WordPress performance depends on multiple interacting layers — infrastructure, delivery, caching, front-end, and data — and optimizing the wrong one wastes effort. Effective optimization starts with measurement: use PageSpeed Insights field data to identify which Core Web Vitals metric is failing, then trace it to the responsible layer. Key thresholds include LCP below 2.5s, INP below 200ms, CLS below 0.1, and TTFB below 800ms. Infrastructure sets the performance ceiling; PHP upgrades (WordPress 6.8+ supports PHP 8.4, 6.9/7.0 support PHP 8.5) improve execution efficiency but won't fix slow queries. Page caching skips WordPress entirely for anonymous visitors, while object caching (Redis/Memcached) reduces repeated database work for logged-in users. CDNs reduce delivery distance for static assets but can't fix slow origin responses. Front-end fixes should target the failing metric: avoid lazy-loading the LCP image, use fetchpriority="high", defer or async JavaScript, and inline critical CSS. For data-heavy sites using ACF, Local JSON reduces field-definition queries, Repeater pagination prevents editor crashes, and moving to custom indexed tables can reduce complex queries from 5+ seconds to under 1.5 seconds.
Table of contents
Key points:How to measure what is actually slowThe infrastructure layer: Hosting, PHP, and the TTFB ceilingThe delivery layer: How CDNs and compression close the distance gapThe caching layer: Page caching and object caching solve different problemsThe front-end layer: Images, render-blocking resources, and the critical rendering pathThe data layer: Database queries, autoloaded options, and the cost of unoptimized custom fieldsWordPress speed optimization: Putting the layered model to workQuestions this post answers
Why does my WordPress site score 95 in Lighthouse but still fail Core Web Vitals in the field?
A Lighthouse score reflects a synthetic lab test under controlled conditions, while Core Web Vitals field data captures real Chrome visits over a rolling 28-day period across actual devices, networks, and locations. A page can pass the lab test but fail at the 75th percentile of real visits because real users encounter slower devices, worse connections, or different page states that the controlled test never simulates. Developers chasing real-user Core Web Vitals improvements track field vs. lab gaps like this on daily.dev.
What is the recommended autoloaded options size limit in WordPress and how do I audit it?
The WordPress performance handbook recommends keeping the combined autoloaded payload below roughly 800KB, treated as an investigation threshold rather than a hard pass/fail. Autoloaded options are loaded near the start of every request regardless of whether the page uses them. Audit the wp_options table for large, rarely accessed, or abandoned plugin entries — and on current WordPress versions include the legacy 'yes' value alongside 'on', 'auto-on', and 'auto' as recognized autoloading values. WordPress developers auditing database overhead find relevant techniques and tooling discussions on daily.dev.
How much can moving ACF custom field data to custom database tables improve query performance?
Moving suitable ACF field data from wp_postmeta into properly indexed custom tables can dramatically reduce query times. One documented test reduced a complex meta query from more than 5 seconds to under 1.5 seconds. The gain comes from proper indexing that wp_postmeta cannot efficiently support for multi-condition filters, sorts, or LIKE searches on serialized values. Custom tables add migration and maintenance overhead, so they are best reserved for workloads that query redesign and caching cannot handle. Teams scaling content-heavy WordPress sites track schema strategies like this on daily.dev.
20.3K Impressions1 Comment