Skip to content 
The first call of a WordPress page often takes longer because the server first „wakes up“ PHP, database and caches and generates the page dynamically. For strong WordPress performance therefore counts how well the page cache, OPcache, database and media work together so that the cold start does not slow you down.
Key points
- Cold CacheFirst call without warm caches costs time.
- Server cold startDormant PHP processes increase the response time.
- Database bloat: Bloated tables make queries sluggish.
- Heavy pluginsToo much initialization slows down the start.
- Page cache: Set preload, rules and exceptions correctly.
Why the first page load is slower with WordPress
WordPress builds the page dynamically when it is first called up: PHP starts, core, theme and plugins initialize, queries retrieve content from the database, then the server renders HTML and delivers it. Without an existing page cache, this process takes longer because no prepared HTML file is available. I often see that the Opcode cache is still cold and PHP files are compiled first. This increases the time to first byte, although subsequent calls appear fast. Only when the caches are filled does the visitor perceive the page as „awake“ and the operation immediately feels faster.
Cold cache: Correctly classifying the cold start effect
A „cold“ cache means that the server does not yet have any static HTML pages and no warm object caching in memory, which is why each component has to work harder. I therefore always schedule a cache preload so that critical pages are pre-rendered in the background. For a systematic comparison, a short Caching comparison between first view and repeat view. This allows me to recognize whether a missing page cache or an inappropriate set of rules is slowing me down. With cleanly set exceptions for login, shopping cart and checkout pages, the Page cache effectively without disturbing dynamic areas.
Sleeping server: What happens when you wake up
Many cheap hosting tariffs throttle processes after inactivity in order to save resources. With the first request, the server must then start PHP workers, load files into the working memory and execute internal routines. This is exactly where the noticeable cold start occurs, which is often described as „first call slow, then fast“. I therefore check how many PHP workers are available and whether CPU and RAM limits are regularly reached. A clever Keep-Alive per cron job can keep processes warm when a tariff change is not an option.
Database bloat and expensive queries
With every revision, draft and plugin, tables and indexes grow, which slows down queries. I limit revisions, empty the paper basket and spam, repair tables and delete orphaned plugin data before measuring again. The leaner the database, the faster the initial query chain, especially without warm object caching. If start pages also run several WP_Query instances with complex filters, the path to the first byte is extended. A regular Cleanup often has a surprisingly positive effect here, even before major conversions become necessary.
Plugins, themes and page builders
Every plugin loads code, queries and assets; some of it is heavier than expected. I sort out resolutely, replace overloaded extensions with lean alternatives and keep everything up to date. Page builders and effects look attractive, but they increase the workload on the first call because many modules initialize and start scripts. A lightweight theme with a clean code base and few external dependencies provides noticeable leeway. Those who reduce render paths win at cold start Milliseconds, that visitors immediately notice.
Images, scripts and the first network overhead
Large images, lots of fonts and external scripts increase the number of requests and the amount of data at startup. I upload images in the right resolution, use modern formats such as WebP and activate lazy loading outside the visible area. For videos, I use preview images instead of immediate embedding so that the browser does not pull additional scripts too early. I use external resources sparingly and prioritize critically necessary files. Fewer requests and smaller files improve the First View immediately.
Use PHP version and OPcache correctly
Current PHP versions deliver much faster than older generations, especially when rendering dynamically. I activate OPcache so that the server keeps compiled bytecode in RAM and does not have to parse it again for every request. If the first request is suddenly slow, I check the OPcache validation, as unnecessary resets destroy the warm state. A healthy OPcache reduces CPU time and measurably stabilizes response times. This helps the Cold start, because PHP has to do less work until the first byte flows.
Using persistent object caching correctly
A page cache only relieves the server of work when it takes effect. If the first call does not fall into the page cache, a Persistent object caching (e.g. Redis/Memcached) because frequent queries for posts, options and metadata come from memory instead of the database. I make sure to bundle central queries and store results as transient or persistently cached objects. A reasonable lifespan is important: TTLs that are too short cause constant recalculation, TTLs that are too long show outdated data. Critical cache keys (e.g. navigation, settings, configuration values) must not be rebuilt every time a page is called up. I define cache groups that are never invalidated and those that are deliberately emptied during content maintenance. This reduces the load on the First-View, although the page is rendered dynamically.
Streamline autoload options in wp_options
During the very first PHP boot, WordPress loads all autoloaded options from the wp_options table. If this block is several megabytes in size, the TTFB increases - even before a single template line has been executed. I regularly check how large the autoload block is, move large, rarely used configurations to „autoload = no“ and only load them where they are needed. Excessive transients, session remnants or debug flags in wp_options unnecessarily bloat the startup. I clean up expired transients, avoid huge arrays/JSON in options and keep the number of option lookups as low as possible. The leaner the options autoload, the less work PHP has to do at cold start - a Quiet lever with a noticeable effect.
Optimize WP-Cron and Heartbeat
A common reason for surprises on the first call are background jobs that start right then: WordPress’ pseudo-cron (wp-cron.php) triggers tasks as soon as a visitor arrives. These include updates, emails, indexers or cleanup work - all things that I would rather not have to do. plannable run via server cron. I deactivate execution on page requests and trigger wp-cron at fixed intervals. I also tame the heartbeat API, which generates requests via admin-ajax: I reduce frequencies on the frontend or switch them off where no live sync is required. This way, the first request is reserved for rendering instead of triggering maintenance jobs at the same time.
Web server and PHP FPM tuning for cold start
In addition to the application code, process control determines responsiveness. For PHP-FPM, I choose a model that does not sleep too aggressively: „ondemand“ saves resources, but generates noticeable cold starts; „dynamic“ with sensible min-spare servers keeps workers ahead. Sufficient max_children prevent requests from ending up in queues. OPcache gets enough memory and appropriate revalidation intervals that neither constantly re-parse nor hold on to the old for too long. In addition, I set realpath and DNS caches large enough and activate HTTP/2 or HTTP/3, Breadstick-compression and keep alive values so that connections do not break unnecessarily. The result: fewer process spins, fewer latency peaks, faster first byte.
Full page cache on the server and on the edge
In addition to classic plugins, I like to use server-side caches (e.g. FastCGI Cache or Varnish) because they are already available independently of WordPress. finished HTML can deliver. I define clear bypass rules for logged-in users and cookies that contain personalization and assign TTLs according to page type: home page and landing pages longer, highly dynamic areas shorter. Stale-while-revalidate keeps pages available from the cache while fresh rendering takes place in the background - ideal against cold starts. On the CDN, I make sure that no unnecessary cookie headers prevent caching and that 301/302 chains do not destroy every edge hit. The more precise the set of rules, the less often WordPress really has to calculate the first view.
Understanding key figures: What I measure
To evaluate the effect properly, I look separately at First-View and Repeat-View. The Time To First Byte shows me how much time the server, PHP and database need until the first byte. I also check First Contentful Paint and LCP because they reflect the perceived speed for users. I repeat measurements with pauses so that caches are cold again and the values remain realistic. A clear Measuring routine uncovers bottlenecks instead of just treating symptoms.
| Metrics | Cold (First-View) | Warm (Repeat view) | Note |
|---|---|---|---|
| TTFB | high | low | Highly dependent on server, PHP and database |
| FCP | medium | low | Characterized by rendering and static assets |
| LCP | medium/high | low | Large images and hero elements are crucial |
| Requests | high | low | Browser cache reduces repetitions |
Cache preload, CDN warmup and prefetch
I have the page cache filled via preload so that the first visitor never has to trigger a cold page. In addition, a CDN warmup, to bring the most important files into edge caches before traffic rolls in. I use Prefetch and Preconnect to prepare the browser for upcoming domains, which reduces handshakes. This results in shorter paths to the first visible content, even at a geographical distance. This Lead time is often the difference between „slow start“ and „right away“.
Cron jobs and keep-alive as a helpful crutch
If the hosting services throttle heavily after idle times, I keep the site active with a cron job. A small ping every few minutes loads caches and ensures that PHP workers don't fall asleep. This is no substitute for good hosting, but it prevents cold starts at peak times. It is important not to choose the frequency too aggressively so as not to exceed the limits. This keeps the site responsive, until a better infrastructure is in place.
Special case home page: Dynamic is expensive
Home pages often bundled many queries: sticky posts, filtered loops, individual blocks and widgets. I reduce dynamic elements, cache query results and rely on more static sections where it makes sense. A server-side fragment cache can also cache individual sections without making the entire page static. This significantly reduces the computational workload when loading for the first time, even if the content continues to vary. The interaction of logic and caching make the difference between seconds and milliseconds.
Hosting and resources: How to scale correctly
A high-performance tariff with sufficient PHP workers, a fast SSD and the latest PHP version makes the biggest difference on the first call. I pay attention to guaranteed resources instead of overloaded shared environments that collapse during traffic peaks. Good providers deliver modern HTTP/2 or HTTP/3 stacks, Brotli compression and clean TLS configuration. This shortens the time to the first byte because the server and network respond more efficiently. Only with sufficient Performance all further optimizations take full effect.
E-commerce and logged-in users as a special case
Stores and communities exacerbate the cold start: cookies for shopping carts or sessions often make pages non-cacheable. I encapsulate personalized areas (e.g. mini-cart, greeting, notes) as fragments that are reloaded via Ajax or cached separately on the server side. Product and category pages thus remain fully cacheable, while only small snippets are dynamic. I also make sure that no unnecessary Ajax endpoints fire on every page and that cart fragments do not block the entire front end. Logged in users benefit from object-based caching and lean queries so that the first click after logging in doesn't seem slow.
Internationalization: Translations without ballast
Multilingual setups load additional language files, which has an impact on the first call. I reduce the number of domains loaded, bundle strings and keep translations in the object cache. I check large .mo files for unused entries and avoid letting translation plugins initialize an unnecessarily large number of text domains on all pages. The more precisely I load what is really needed, the lower the overhead for the First-View.
Maintenance and monitoring: staying on top of it pays off
I regularly check whether updates, new plugins or theme changes delay the loading time. Monitoring for CPU, RAM, I/O and PHP workers shows me when bottlenecks occur, especially after idle periods. If measurements are conspicuous, I work on the cache, database and plugins one after the other until the first call is stable again. A clear change plan helps to avoid mixing cause and effect. This keeps the WordPress page reliably fast - even on the first visit.
Briefly summarized
The sluggish first page load is caused by dynamic generation, cold caches and throttling server processes. I counteract this by using page cache with preload, keeping the database and media lean, maintaining PHP including OPcache and removing unnecessary plugins. Clean measurement routines for TTFB, FCP and LCP show me where I need to start. Good hosting and optional keep-alive prevent the server from „falling asleep“ again. If you use these levers consistently, you noticeably reduce the cold start and strengthen the WordPress performance permanent.
