PerformanceIntermediate
How to diagnose a slow WordPress site
Find whether WordPress slowness comes from the server, images, scripts or interactions. Measure repeatable changes and separate lab from field data.
WordPress performance
A faster site starts with a better diagnosis.
Find the slow part, measure it, and change one thing at a time. A useful speed improvement still leaves your site working.
Browse resources
5 resources
MediaIntermediate
How responsive images work in WordPress
Understand WordPress image sizes, srcset and sizes, then check what the browser downloads and improve oversized or missing responsive images.
Performance & cachingIntermediate
WordPress caching plugins: choose the right cache
Understand page, object and browser caching in WordPress. Compare documented WP Super Cache and LiteSpeed Cache requirements without stacking tools.
ImagesIntermediate
WordPress image plugins: features and trade-offs
Choose image optimization by compression, resizing, format delivery and privacy. Understand EWWW’s documented options and protect original uploads.
Design & customizationBeginner
How to change fonts in WordPress
Change site-wide WordPress fonts with Styles, understand classic-theme options, and choose readable typography without loading unnecessary font files.
Start with a repeatable problem
Choose a slow page and record the device, network, logged-in state and measurement tool. Repeat a lab run to account for variation. Field data describes real users over a reporting period; lab data describes a controlled run. Neither should be presented as an invented benchmark.
Work through the request
A long wait for HTML suggests investigating server processing and cache behavior. A large image request calls for image work. A busy main thread can affect interactions, while missing reserved space can cause layout shifts. These are starting points; a request timeline or performance trace supplies stronger evidence.
Ask the host about resource limits and page caching. Object caching is a different layer from serving a complete cached page. Keep personalized responses, carts and account pages protected by the application's documented exclusions.
Read Core Web Vitals in context
Google's current Core Web Vitals are LCP, INP and CLS. The good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile of page visits. These are field-oriented user-experience measures, not a promise made by a plugin.
Use web.dev's current definitions and LCP diagnosis. A low-traffic page may have no sufficient field data. Do not replace that missing evidence with an estimated score.
Make changes you can explain
Keep a log of the original problem, change and repeated result. Reduce excessive images, unnecessary font weights and third-party scripts when evidence identifies them. Test forms, navigation and checkout after changing script-loading behavior.
A theme or plugin's effect depends on the actual page and host. Count alone is weak evidence. Use staging to isolate an expensive feature before removing something visitors need.
Diagnose a slow site for the complete sequence. The WordPress performance handbook provides server and application context. Documentation checked October 7, 2026.