Who this checklist is for

Teams maintaining an active WordPress site that must reduce network transfer and server runtime energy will find this checklist useful. The guidance assumes an existing site with dynamic pages, media content, and a third party theme or page builder. The aim is to give clear actions you can apply incrementally and measure at each stage.

Core principles to follow

Prioritize changes that cut repeated work for every request. Reduce bytes transferred. Shift compute to cacheable or offline processes. Prefer simple, predictable client render paths over heavy runtime JavaScript. Validate each change with measurement so feature trade offs are visible.

Step 1 measure and baseline

Before making changes capture metrics so you can compare. Key metrics include page weight in bytes, number of requests, server response time for cached and uncached requests, time to interactive on representative devices, and real user median page load where available. Record a small sample of pages that represent home, high traffic landing pages, and a content heavy page with many images. Use lab tools and field data if possible.

What to record

Record the unoptimized payload size for HTML CSS JavaScript images and video. Record server CPU time or duration of PHP responses for uncached requests. Capture cache hit ratio from any existing caching layer. Note user device profiles and geographic distribution to guide CDN placement decisions.

Quick measurement tools

Use a combination of controlled lab tests and real user monitoring. Lab tools give comparable before and after numbers. Real user monitoring reveals the distribution of device types and network conditions that determine where optimizations matter most.

Step 2 implement caching layers in the right order

Treat caching as multiple cooperating layers. Implementing them in the wrong order wastes effort. Start with a full page cache, then add an edge CDN, then an object or database cache, then opcode caching.

1. Page cache Implement a page level cache that can serve complete HTML for anonymous users from memory or filesystem to avoid PHP execution. Configure cache invalidation for content updates only rather than short time to live values. Ensure cache keys include minimal necessary variables such as protocol and language. Avoid fragmenting the cache unnecessarily with cookies or query parameters.
2. CDN in front of the origin Add an edge CDN to serve static assets and cached HTML from locations near users. Configure the CDN to respect origin cache headers or set sensible TTLs for assets that change rarely. Use origin shielding or a regional POP to reduce origin load if your CDN supports it.
3. Object and database cache Enable an in memory object cache for persistent processes to reduce repeated database queries when the page cache misses. Use a separate service such as Redis or Memcached and keep cache keys stable across deployments. Cache expensive computed objects rather than raw query results when possible.
4. Opcode cache Ensure the PHP runtime uses an opcode cache. That reduces CPU and response time for uncached PHP requests without changing code.

Configure cache headers for static assets to allow long lived browser caching and use versioned filenames for updates. Minimizing origin hits and repeated compute yields consistent reductions in server energy use for each user request.

Step 3 optimize the media pipeline

Images and video dominate bytes on many pages. Focus first on the high traffic pages and formats that largest audiences use. Automate as much of the media pipeline as possible so content editors cannot deploy very large files by accident.

Responsive images and sizing

Generate and serve appropriate image sizes using srcset and sizes or picture where you need art direction. Precompute a set of widths that match your responsive breakpoints. Avoid serving a larger image and relying on client side resizing.

Modern image formats and format negotiation

Produce WebP or AVIF versions and serve them when supported by the browser. Use server or CDN level format negotiation so cached variants are correctly separated by Accept headers. If using an image CDN that supports automatic format negotiation enable it rather than trying to detect on the origin.

Image delivery choices

Decide between pre generation and on the fly resizing. Pre generation produces predictable CPU use during builds or uploads and works well for stable catalogs. On the fly resizing moves compute to the image service or CDN which can be cache friendly if cache keys include size parameters. For sustainability choose the approach that minimizes repeated compute for your traffic patterns.

Lazy loading and priority images

Enable lazy loading for non critical images so initial byte transfer focuses on above the fold content. Mark hero and other immediately visible images as high priority so they load early. Avoid automatically lazy loading images that are likely visible on initial paint.

Video guidance

Prefer streaming and adaptive bitrate delivery for long video instead of embedding large progressive downloads. Use poster images and avoid autoplay with sound. Only embed third party video players when they are necessary and ensure they are loaded after core content if possible.

Step 4 choose or tune a theme for low runtime cost

The theme determines runtime DOM size CSS weight and client side JavaScript. Audit your current theme for large style sheets inline critical CSS and heavy client side frameworks. Where replacements are needed prefer themes that use server rendered markup and minimal JavaScript for interactivity.

Decision criteria for themes

Prefer themes with small DOM depth and predictable markup that supports caching and critical CSS extraction. Avoid themes that inject heavy inline styles per page or that rely on large page builder runtimes unless those features are essential to user tasks. If you must keep a page builder evaluate embedding its output as static cached HTML for public pages.

Tune rather than rewrite when possible

If a full theme replacement is not feasible focus on removing unused features and large third party scripts. Defer non critical widgets. Consolidate fonts and icon sets to reduce multiple resource requests. Extract critical CSS for above the fold content and load the rest asynchronously where feasible.

Step 5 hosting and runtime configuration

Choose hosting and PHP configuration that reduce per request energy use. Use newer supported PHP versions as they are more efficient. Ensure the environment has an opcode cache enabled and enough memory to avoid frequent process restarts. If your traffic can be served as static HTML consider a build step to export pages and host them on a static hosting platform with a CDN.

Database and background tasks

Move heavy cron style work to scheduled background jobs that run at off peak times and are rate limited. Cache computed query results and avoid expensive joins on high traffic endpoints. Monitor slow queries and add indexes selectively rather than increasing hardware as a first step.

Step 6 deploy incrementally and measure impact

Apply changes in small increments and measure the same pages you captured during baseline. Track page weight cache hit ratio and server response time. Use feature flags or staged rollouts to control exposure and to be able to revert quickly. Document each change and the observed effect so future teams can see what worked.

Monitoring signals to watch

Watch cache hit rates CPU and memory usage on the origin number of bytes transferred from the origin and real user metrics for the slowest 10 percent of devices. Correlate content changes with cache invalidations to avoid surprises after content publishes.

Operational rules to keep the site low carbon over time

Set commit hooks or upload checks to prevent editor uploads of oversized images. Add a maintenance task that reports the top heavy pages by bytes and number of requests. Include cacheability checks in your release checklist and require that new features document their expected cache behavior and invalidation conditions.

Making WordPress more sustainable is an iterative engineering effort. Small predictable changes to caching media and theme choices add up because they reduce work for every visitor every time. Measure each change test the real user experience and keep the delivery pipeline accountable to those metrics.