Choose based on what your site does and who uses it

Start by matching technical choices to the site profile. A brochure site with few pages and mostly static content needs a different approach from a frequently updated ecommerce site or a membership site with per user content. Make a short inventory that records the following for each site: traffic pattern during the day, percentage of repeat visitors, content type that drives most page weight, and whether HTML output must be personalized per visitor. Those facts determine whether to prioritise aggressive edge caching, fine grained cache controls, or server side object caching.

Decision criteria to guide choices

High read traffic and mostly public pages favour long time to live values at the CDN and page cache on the origin. High update frequency or frequent personalization favour shorter TTLs, cache purging integrations, and using edge functions for small personalization fragments. Media heavy sites need an image pipeline that does resizing, format negotiation and efficient delivery at the CDN edge.

Caching options and practical settings to try

Caching reduces server compute and network transfer when configured to match the content freshness requirements. Use a layered approach: browser cache, CDN cache, origin page cache, and object cache for dynamic database driven work.

Page cache

Page caching stores full HTML responses and is the largest win for many sites. Choose a plugin or server feature that supports cache purging when content changes and that can bypass cache for known authenticated journeys. Recommended behaviours to test on a staging environment include the following:

• Enable full page cache for anonymous users only.
• Set cache control headers with a conservative time to live for pages that change often and a longer value for stable landing pages.
• Integrate cache purging with your publishing workflow so post updates clear related URLs automatically.

Object cache and database caching

For sites with complex queries, an in memory object cache reduces repeated database work. Use Redis or memcached where supported by your host. Validate that cached objects have sensible expiry and that cache keys do not unintentionally include volatile data. Monitor cache hit rate and be ready to fall back if stale data creates visible errors.

CDN and edge caching

Put static assets behind a CDN and tune two things primarily: the cache key and the time to live. Keep cache keys simple so different user characteristics do not fragment cache effectiveness. Avoid adding unnecessary request headers into the cache key. Use origin shielding or a regional POP to reduce origin requests for global traffic. Configure the CDN to compress and to negotiate modern transport features where available.

Media pipelines that prioritise data efficiency

Images and video are often the largest part of a page weight. The aim is to deliver images sized for the user viewport, in an efficient format, and from a cache close to the user.

Responsive images and sizing

Use the native responsive image attribute that WordPress outputs by default where possible. Ensure the srcset and sizes attributes represent the real layout widths of images on different breakpoints. Where images are inserted by third party blocks or builders that do not emit proper attributes, consider replacing those blocks or inserting optimized HTML through a custom block.

Modern formats and conversion

Convert master image uploads to modern formats such as WebP while keeping a fallback path if some clients need it. Prefer on upload conversion or build time conversion rather than repeated on the fly conversions on the origin. If you use on the fly conversion at the CDN edge, verify the CDN caches the generated variants rather than proxying every request back to origin.

Resizing and delivery choices

Offer only the sizes that are consumed by templates and components. Avoid keeping very large master images that are always scaled down in the browser. Use a pipeline that can produce defined size variants and remove unnecessary originals. For photo heavy sites consider automated rules to create a small set of common widths and a progressive loading strategy for high density screens.

Lazy loading and video behaviour

Enable native browser lazy loading by including the loading attribute for images and iframes. For videos, prefer lightweight poster images and load the player only on user interaction for embeds that do not autoplay. Avoid autoplay with sound because it creates unnecessary CPU and network work with low user value.

Theme choices that reduce runtime work

The theme determines a large part of client side JavaScript, CSS size and DOM complexity. Prioritise themes that render server side with minimal runtime scripting and that do not ship large builder frameworks unless you need them.

What to prefer in a theme

Choose a theme that produces mostly semantic HTML, defers non essential JavaScript, and limits large CSS frameworks. Evaluate the theme on three practical criteria: initial HTML size and structure, total CSS and JS shipped to anonymous users, and how many third party requests the theme triggers. Use the theme above a minimal block library or a lightweight starter rather than a full size visual builder where possible.

When a builder is acceptable

If a builder is essential for business workflows, limit its use to the pages that require it and serve simpler templates to most pages. Many builders offer an option to disable the front end editor assets; enable that option so editor scripts do not load for anonymous visitors.

Recommended plugin and configuration patterns to test

Plugins can implement the behaviours above but plugin selection should follow the rule of least privilege. Pick plugins that do one job well, that are actively maintained, and that expose configuration for caching and formats so you can verify behaviour.

• Page cache plugin that supports automatic purge on content changes and conditional bypass for logged in users.
• Image optimisation plugin that can generate WebP variants on upload and keep a clear fallback rule, or an image CDN that offers format negotiation at edge.
• Asset optimisation plugin that defers non critical scripts, concatenates carefully if needed, and lets you exclude specific scripts that break functionality.
• Object cache integration with Redis or memcached for database driven sites with heavy queries.

Testing, measurement and verification

Measure before and after every change. Use synthetic tools to check lab performance and field tools to monitor real user impact. Key checks to run include the following

• Lab test with Lighthouse to capture metrics such as largest contentful paint and total blocking time and to see how changes affect payload.
• Network waterfall capture to ensure caches return hits and to confirm images are delivered in the intended sizes and formats.
• Real user monitoring for a week after deployment to observe any regression on core web vitals or conversion metrics.

When testing caching, include these validation steps: request pages from a clean cache, repeat requests to confirm cache hits, then publish an update and confirm automatic purge behaviour. For image pipelines validate that the CDN or plugin serves a WebP variant for compatible clients and that fallback formats are available for clients that require them.

Operational practices that keep carbon low over time

Performance is not a one time project. Build a small runbook that covers when to adjust TTLs, how to add or remove image sizes, and how to safely toggle theme features. Include automated checks in your deployment pipeline that run a quick Lighthouse audit and fail the deploy when a clear regression is detected. Keep monitoring on for cache hit rate and average payload size and set simple alerts for sudden increases.

Document decisions and trade offs

Record why you chose a cache TTL or why certain sizes are produced. That documentation helps future editors understand why removing a generated size might be harmful or why a theme change requires a staged rollout. Good documentation reduces unnecessary rework and prevents adding inefficient features that increase data transfer.

Quick implementation checklist

1. Inventory pages, traffic patterns and content types.
2. Enable page cache for anonymous users and configure purge rules for content changes.
3. Put static assets behind a CDN and remove volatile headers from cache keys.
4. Set image conversion to create WebP and defined size variants on upload or at build time.
5. Enable native lazy loading for images and defer media heavy embeds until interaction.
6. Choose a theme that minimises client side JavaScript and avoid builder assets on public pages.
7. Introduce object cache only if database query load justifies it.
8. Run lab and field tests before and after each major change and keep monitoring active.

Follow these steps incrementally and measure each change. Small controlled changes avoiding sweeping rewrites often produce the best trade offs between user experience and lower resource use.