Site Speed Best Practices
The purpose of this task is to clarify the two distinct areas that impact site speed (front end load time vs back end), and to address the common cycle our team gets stuck in when working on speed-related tasks. While we have strong familiarity with front-end optimization tools like WP Rocket, Airlift, FlyingPress and NitroPack, these tools only cover half of the picture when it comes to troubleshooting site speed: when the performance issues occur during the Time to First Byte (TTFB), or if the optimized/cached version isn’t being properly served, or the backend of the site is slow, or the site gets PHP memory limit errors, no amount of settings-tweaking will resolve the underlying problem. We need to ensure we’re taking the right approach for each situation with this in mind, and become fluent in these concepts internally and when managing client expectations – feel free to leave any questions in the comments!
1. Front-End Load Time (Rendering & Assets – where we are familiar)
Our tools like Airlift, WP Rocket & NitroPack specifically address front end load time. 80-90% of the time these tools are able to dramatically improve site speed with their default settings – sometimes requiring a bit of manual work (or interfacing with Airlift support) to resolve any conflicts / breakage. All of these tools do some combination of the following:
- Minifying and combining CSS and JS files
- Lazy loading images and videos
- Optimizing fonts and media formats
- Using a CDN to deliver assets faster
- Deferring non-critical scripts
- Creating cached static versions of the site
However if these tools and their various settings aren’t yielding results, it’s time to move on to:
2. Time to First Byte (TTFB) – Site codebase / plugin stack & db resource usage
This is often the source of confusion and where we tend to get stuck. TTFB refers to how long it takes the site’s codebase and database to process requests, run queries, and execute plugin and theme code before the browser starts to load anything (along with DNS resolution, TLS etc – which we won’t cover here).
If this is slow, front-end optimization tools will not help. No matter how much we adjust WP Rocket, Airlift, or NitroPack, we will not see improvement if the site itself is slow to generate the page at the server level, or if something is preventing the cached version from being served. This goes for backend/admin slowness and php memory errors as well.
In this case we need to audit plugins, database load, and theme performance, and check if anything is preventing cached pages from being loaded. This requires a dev who understands how to use Pressable’s APM tool, Query Monitor and/or wp profile in CLI to diagnose and isolate the offending code (or cumulative bloat), and to suggest alternate solutions. PMs should be prepared to engage with the client and work with a skilled dev to properly scope manual work that may come out of this – if structurally the site is completely bloated with too many plugins or a poorly written theme, expectations need to be managed around the potential for more intensive project work / rebuild, vs drawing out the troubleshooting using non-applicable front-end tools.
Causes of slow TTFB:
- Heavy or bloated plugins, poorly written custom code
- Inefficient database queries or very large databases
- Themes with heavy codebase or inefficient page builders
- Sites with high traffic or complex dynamic content causing high PHP and resource usage
- WooCommerce load with large product catalogs or complex configurations
- PHP errors and warnings (check logs)
Common mistakes:
- When our team cycles between various caching, minification, cdn settings without improvement on the frontend, it’s usually because TTFB is the root problem, or something is preventing the optimized/cached version from being loaded. We need to come to the understanding quicker when TTFB / backend load is the the culprit and escalate to a dev to assess.
- Similar to the above – when the client reports backend slowness or memory limit errors, this is not fixable with WP Rocket, Nitropack, Airlift, FlyingPress etc. This is a memory leak and needs a developer to isolate the issue.
Dev troubleshooting steps for TTFB:
- Verify if the cached, optimized version is actually being served
- Check PHP error logs for active errors or warnings
- Use Query Monitor plugin to identify slow database queries and heavy plugins.
Note: Best used on staging, as it adds load in production – always make sure to disable on the live site when finished.
- Use WP-CLI’s profile command to profile hooks, functions, and database queries for bottlenecks (advanced, requires dev). Instructions for installation here – ping Pressable if you need help.
Other important considerations
- Logged-In users will always see unoptimized site
Logged-in users (including clients) will always see the uncached version of the site. If a client is logged into the site while browsing and assessing speed (happens frequently), they won’t see any benefits from caching or front-end optimizations. Always instruct clients to log out or use an incognito/private window when reviewing site speed.
- Cache conflicts – Plugin conflicts, misconfigurations, or security settings can prevent the plugin-optimized, cached versions of pages from loading, or cause them to load intermittently. In this case it’s helpful to disable all layers of CDN, caching etc and make sure only one tool is in use (Airlift, WP-Rocket, Nitropack).
- Dynamic pages and woocommerce
Pages like Woocommerce cart, checkout, or user account areas often bypass caching for functional reasons. These will naturally load more slowly than cached static pages.
- External Services / 3rd party scripts
Third-party services such as chat widgets, analytics tools etc can negatively affect performance. These services are loading assets from their own servers outside of Pressable which we do not control, with codebases that we also do not control. Deferring JS can definitely help here with real-feel, but the pagespeed metrics may still take a hit from these scripts.
In summary, site speed is a cumulative result of both fast asset delivery (frontend) and a fast backend (which impacts TTFB). While our tools can optimize front-end load time, high TTFB – often due to bloated code, inefficient queries, or excessive plugins – requires deep, hands-on development work and code audits. This means one-click solutions won’t always cut it, and we need to manage client expectations, internal processes and scoping accordingly.