What makes a website fast? From DNS to PHP workers

Introduction

A fast website might seem simple, but in reality there’s a whole chain of technical steps involved. Every time someone visits your site, the request passes through multiple layers — from the DNS lookup to PHP worker execution and finally rendering in the browser. In this article we go a bit deeper into the technical side to explain which components contribute to website speed (including perceived performance, or how fast the site feels to a user). We focus mainly on the server-side (for example a PHP-based site like WordPress), but we also cover front-end optimizations. You’ll see why certain components become bottlenecks and what you can do about them.

The goal isn’t to overwhelm you with jargon, but to give an accessible view of the full route a page request takes — and how each link affects performance. That way you learn where you can gain speed, and you understand how a good hosting provider optimizes these aspects for you.

DNS: the starting point of every request

A web page’s journey starts with DNS (Domain Name System). This system translates the domain name a user enters into the numeric IP address of the server. Although this happens behind the scenes, DNS resolution speed can have a noticeable impact on total load time. On average, a DNS lookup takes around 20 to 120 milliseconds. That sounds negligible, but analyses show that once DNS resolution exceeds ~100 ms, users can feel the delay. In other words: every millisecond counts.

Why does DNS matter so much? Until the domain is resolved to an IP address, the browser can’t even reach the server. A slow DNS server or complex DNS configuration (for example many CNAME hops) means a delayed first step. In practice you can improve this by using a fast DNS provider and keeping DNS records simple. Browsers also cache DNS results for a while; repeat visits don’t need to perform the lookup again as long as the TTL (time-to-live) hasn’t expired.

Practical tip: Choose a DNS solution known for fast response times and global coverage. Premium DNS services or CDN DNS can often keep resolutions under 100 ms. Also avoid unnecessary DNS indirection; for example, if your site loads resources from external domains, consider DNS prefetching or limiting the number of different domains to minimize first-visit delays.

Network connection and latency

Once DNS lookup is done, the browser knows which IP to reach. The next step is establishing a network connection with the server. Latency (round‑trip delay) plays a major role here. The farther the user is from the server, the higher the latency tends to be. Put simply: distance adds travel time. A visitor in the Netherlands accessing a site hosted in the Netherlands might see ~20 ms latency, while the same site accessed from the US could experience 100+ ms due to distance.

Rule of thumb: the closer the server is to your users, the faster the first connection is established. In other words, proximity reduces latency and improves load time. That’s because data literally travels a shorter path between user and server. High latency directly translates into slower page experiences and can even impact conversion rates; for example, 100 ms of extra delay can already have a measurable negative impact (~1% less revenue) on online sales.

Fortunately there are ways to reduce network latency:

• Server location and CDN: Host your server as close as possible to your primary audience. If most visitors are in the Netherlands, use a Dutch/EU data center. For international audiences, use a Content Delivery Network (CDN) that distributes your content across servers worldwide. A CDN ensures static assets (images, scripts, stylesheets) are delivered from a location close to the user, reducing wait time. In many cases a good CDN reduces latency from hundreds of milliseconds to under 50 ms for distant users.
• Network infrastructure: A quality hosting environment connects to fast networks and internet exchanges. That means fewer hops and more efficient routing. You don’t control this directly as a customer, but you can choose a provider with strong networking.
• Protocols and compression: Modern protocols like HTTP/2 and HTTP/3 use connections more efficiently (for example multiplexing multiple files over one connection). Techniques like gzip/Brotli compression reduce the amount of data transferred, which especially over longer distances saves time.

In short, you want hosting location and infrastructure that match your visitors. You can’t eliminate latency completely (the speed of light is the limit), but you can reduce it significantly through smart geographic choices and technology.

TLS handshake and HTTPS

Today almost every website runs on HTTPS for an encrypted connection. This is essential for security, but adds an extra step: the TLS handshake. When establishing an HTTPS connection, browser and server first “shake hands” cryptographically to exchange keys and create a secure tunnel. This process typically requires a few network round trips between client and server.

The performance impact depends on TLS version and distance:

• TLS 1.2 (previously common) required two round trips (2‑RTT) to complete the handshake. If one round trip takes 50 ms (on a nearby server), the handshake alone already adds ~100 ms before any data flows. For distant servers it’s more.
• TLS 1.3 (modern standard) optimized the handshake to a single round trip (1‑RTT). That halves handshake time compared to TLS 1.2. TLS 1.3 also supports “0‑RTT” session resumption, which for repeat connections costs almost no extra round trip.

For users, this means HTTPS now adds little noticeable delay, as long as modern techniques are used. Still, it’s worth considering: an HTTP/3 connection (based on QUIC) or TLS 1.3 will generally establish faster than older protocols. Hosts should keep TLS configurations up to date.

Practical tip: Use TLS 1.3 where possible and ensure a clean configuration (short certificate chain, HTTP/2 or HTTP/3 support). That minimizes encryption overhead without compromising security.

Server response and TTFB

Once the network connection (including TLS) is established, the browser sends the HTTP request for the page. Now it’s about the server: how quickly can it process the request and start returning a response? The time until the first byte of the response arrives is measured as TTFB (Time To First Byte). TTFB is often seen as an indicator of back‑end speed and server responsiveness.

Important to understand: TTFB covers the time from the request (after DNS/connection) until the first response byte. That includes:

• Wait time and processing on the server: the server must assemble the page or fetch the file.
• Network delay before that first byte reaches the user.

As a guideline: a TTFB under ~200 ms is excellent, 200–500 ms is fairly normal, and anything above ~600 ms suggests potential issues. A consistently high TTFB means your site “thinks” for a long time before anything happens. To users, that feels slow, regardless of how fast the rest of the content might load.

The most common cause of slow server response (high TTFB) is dynamic content generation. In a CMS like WordPress, that means PHP code runs and executes database queries to build the page. Each step can be a bottleneck:

• PHP execution: Is the code efficient? A heavy theme or plugin doing unnecessary computation can slow processing.
• Database queries: If dozens or hundreds of queries run per page, or a few very slow queries, output is delayed.
• Server resources: Lack of CPU or memory, slow disk I/O, or general server overload can increase processing time. On shared hosting, resources are shared; if the server is busy with other sites, your TTFB can rise too.
• External waits: Sometimes the server waits on external systems, such as an API call or third‑party script, which can significantly slow the response.

A handy way to diagnose TTFB issues is to compare a static file versus your dynamic page. Does a simple test.html from the same server load instantly (<100 ms) while your WordPress page takes 800 ms? Then the delay is in the application layer (PHP/DB), not the network or hardware.

Optimizations for server response focus on reducing work per request, especially for popular pages. Caching (next section) is key: storing results temporarily means PHP + database don’t have to run on every request. You can also update or remove inefficient plugins, clean autoloaded data in the database (so WordPress doesn’t load unnecessary bulk on every page), and make sure you have sufficient server capacity. Managed hosting often monitors and optimizes these for you, but you can also use tools like Query Monitor to find bottlenecks (see the database section).

PHP execution and PHP workers

For WordPress and other PHP‑based websites, PHP execution is the core of server‑side processing. When a request comes in that isn’t a static file, the web server (Apache/Nginx) passes it to PHP. PHP starts the CMS, loads all required code (core, theme, plugins), and runs the logic to construct the page. This naturally takes time and compute resources.

In modern hosting environments PHP often runs in a PHP‑FPM worker or similar process. You can think of a PHP worker as a dedicated “workhorse” that handles one request at a time. If you have 4 PHP workers and 8 concurrent requests that require PHP, 4 are handled immediately and the other 4 must wait for a worker to free up. It’s like checkout counters in a store: if all are busy, a queue forms. For websites, that means new requests wait longer, or in worst cases you get timeouts or errors if the queue grows too long.

Number of PHP workers

On shared or managed hosting there’s usually a limit to the number of concurrent PHP processes per site. A basic plan might allow 4–6 PHP workers, while higher tiers provide more. Some hosts allow “bursting” — temporarily borrowing extra workers during traffic spikes — but there is always a ceiling. It’s important that your site doesn’t send every request through PHP unnecessarily. Caching and offloading tasks help a lot here.

Why do PHP workers get overloaded?

Common causes:

• No caching: Every page view triggers full PHP execution and database work, even for pages that rarely change. This can easily consume all workers with moderate traffic.
• Long‑running processes: For example a plugin running a large export or backup can occupy a PHP worker for a long time, while other traffic queues up.
• Traffic spikes on uncached pages: Imagine you send a newsletter and 1,000 people click a personalized link that can’t be cached; without enough workers, many will have to wait. DDoS or bot traffic that isn’t cached can also tie up workers.
• Inefficient code or external calls: A poorly optimized plugin or a theme that calls an external API for every visitor can slow each PHP execution.
• Cron jobs and background tasks: WordPress uses pseudo‑cron via wp-cron.php. If a heavy scheduled task runs during peak hours, it can also occupy a worker in the background.

The goal is to keep PHP processes as “light” as possible: let them only do what’s necessary. Caching is your best friend here: a fully cached page doesn’t touch PHP at all; the web server can return the stored HTML directly. Partial caching helps too: if certain data is already in a fast cache, the PHP worker finishes faster and becomes available sooner.

Think of a webshop: the homepage and product pages can be served from cache for logged‑out visitors, keeping PHP workers free for truly dynamic things (cart, checkout). Hosts often work this way too: WooCommerce product and category pages are cacheable, but personal pages like “my account” or the cart are not — those must be handled by PHP and need to be efficient.

Practical tip: Monitor your site for signs of PHP worker exhaustion. If pages slow down under concurrent traffic or logs show “PHP worker exhausted,” it’s time to scale or optimize. Optimization (caching, improving code) is often the first step — adding more workers only helps up to a point if the code itself is slow. A good host will show cache hits vs. misses and CPU usage so you can see if you’re hitting limits.

Database performance

Another crucial link in the server‑side chain is the database. For WordPress that’s usually MySQL/MariaDB. Every time PHP needs content — a blog post, a list of products, user data — it runs one or more database queries. Query speed directly affects how fast the page can be built.

Key factors for database performance:

• Number and complexity of queries: The more separate queries, the more total time spent. A standard WordPress page already runs dozens of SELECT queries. Plugins can add extra queries (for related posts, stats, etc.). If this grows to hundreds per page, delays become noticeable. Heavy queries (joins over large tables, missing indexes, etc.) can take hundreds of milliseconds each, which adds up.
• Database configuration and resources: Is the database on the same server or external? Does it have enough memory for caching (e.g. innodb_buffer_pool)? On shared hosting this is hard to control, but on your own server you can tune it so frequently used data stays in RAM. Storage matters too (SSD vs HDD). Most modern hosting uses SSD/NVMe, which significantly speeds up random reads/writes.
• Indexes and optimization: Good indexing allows the database to find results quickly. WordPress core tables are well indexed, but custom tables created by plugins may not be. A single missing index on a frequently filtered column can slow queries dramatically.
• Connection latency: If the database is on a different server than the web server, that adds network delay per query. In a good data center this is only milliseconds, but it adds up. That’s why databases and web servers are usually placed close together on fast internal networks.

What can you do? On shared or managed hosting you have limited direct control, but there are still several approaches:

• Use query caching or object caching: WordPress has a built‑in object cache layer — results of database queries can be stored temporarily so subsequent requests fetch them from memory instead of querying the DB again. By default this cache isn’t persistent (it resets each request), but with a plugin you can enable persistent object caching (via Redis or Memcached). This can be a huge win because frequent queries then return in microseconds. Many managed hosts offer Redis caching to make this easy.
• Optimize slow queries: With tools like Query Monitor (WP plugin) or New Relic APM you can identify the slowest queries. Sometimes the fix is a plugin update or better configuration. For example, a search function without a full‑text index will be slow — adding such an index can help significantly.
• Clean up the database and autoloaded data: Over time, WordPress databases can fill up with unused data (transients, post revisions, tables from old plugins). Cleaning this up (with plugins like WP‑Optimize, Advanced DB Cleaner, etc.) makes the database leaner and faster. Autoloaded data (entries loaded on every page from wp_options) also matters. If megabytes of unused options are autoloaded, every page slows down. The recommendation is to keep autoloaded data under ~800 kB.

In short: the database is often the beating heart of a dynamic site. Treat it carefully: keep it clean and don’t let it grind through heavy queries unnecessarily. Where possible, reduce load through caching (next section).

Caching on every layer

If there’s one theme running through the topics above, it’s caching. Caching means storing results that have already been calculated or fetched, so they don’t need to be recomputed next time. You can apply this principle across multiple layers of the web stack, and ideally you use them together:

• Page caching (full page caching): Store the complete HTML output of a page after it’s generated once by PHP/WordPress. The next visitors get that ready‑made HTML directly, without PHP or database work. This is hugely effective, especially for pages that are the same for everyone (blog posts, category pages, landing pages). WordPress plugins like WP Super Cache, W3 Total Cache, WP Rocket, etc. do this, or it’s built into your host. Result: PHP and database are bypassed for most visitors, reducing load dramatically and bringing TTFB close to static levels (often <100 ms).
• Object caching: As mentioned earlier, object caching stores results of expensive database queries or computations in memory. With a persistent object cache (e.g., Redis), WordPress can reuse cached data instead of querying the database. This helps especially for pages that can’t be fully cached but still rely on repeat queries. For example, a site with shared sidebar data or menus benefits because those don’t hit the database every time.
• Opcode caching: This targets PHP itself. PHP code normally has to be parsed and compiled into machine‑readable opcode each time a script runs. With OPcache, compiled code is stored in memory so subsequent requests don’t need to parse it again. On modern hosting OPcache is usually enabled by default. It speeds up PHP execution by reusing compiled bytes.
• Browser cache and CDN (edge caching): This is caching at the “front”. You can tell visitors’ browsers to store certain files locally — images, CSS and JavaScript don’t change often, so after the first download, subsequent pages can load them from cache. This works via HTTP headers (Expires or Cache‑Control) that your server or CDN sets. Google often recommends caching static assets for at least a year (unless their filenames change with updates). CDNs can also act as caches: they store copies of your content on edge servers. A well‑integrated hosting setup often uses multiple caching layers: edge caching (CDN), server‑level page cache (like Varnish or Nginx FastCGI cache), and object cache (Redis/Memcached). These layers intercept requests before they reach the PHP/database core.

It’s important that caches don’t fight each other but complement each other. For example: your page cache (e.g., WP Super Cache) stores HTML, and your CDN caches it on edge locations. Ideally the CDN serves HTML directly to distant users (saving latency) while local users get HTML from the server cache. The object cache handles database hits for pages that aren’t served from HTML cache (e.g., personalized content). The browser cache ensures that on the next click, assets don’t need to be downloaded again. When each layer does its job, even a heavy WordPress site can feel extremely fast with relatively little server load.

A challenge with caching is invalidation: when content changes, the cache must be refreshed. Good cache systems (plugins or hosts) handle this smartly — for example, by clearing cache for a page when it’s updated, or when a product goes out of stock so customers don’t see stale info. In managed hosting this is often handled behind the scenes.

Practical tip: Use caching wherever possible, especially on shared hosting. Install a reliable cache plugin or choose hosting that provides caching out of the box. Just make sure you’re not running conflicting caching mechanisms (for example two page‑cache plugins at once). And test your site after enabling caches — does everything still look right? There are often exceptions (dynamic content that must not be cached, like cart contents). But for 90% of pages, caching equals speed.

Front-end optimizations and perception

So far we’ve looked at everything that happens before the browser can actually render the page: DNS, networking, server, PHP and database. But the front‑end (the user side) also determines total load time and perceived performance. This is how fast the site feels, which doesn’t always match how quickly every byte finishes loading.

Key front‑end factors that affect speed:

• Number and size of resources: Every extra image, script or stylesheet is another download. Thanks to HTTP/2, multiple files can arrive in parallel over one connection, but still: fewer is faster. Combine files where it makes sense (or use HTTP/2 server push / HTTP/3), and remove unnecessary assets. Heavy third‑party scripts (tracking pixels, social embeds) can slow everything down.
• Image optimization: Large uncompressed images are common culprits for slow sites. Serve images at the right size (no 4000px photos displayed at 400px) and compress them (JPEG, or better, modern formats like WebP/AVIF). Plugins like Smush or EWWW Image Optimizer can automate this. Lazy loading is now standard: images below the fold load only when they’re about to appear, reducing initial payload.
• CSS and JavaScript: These must be loaded and parsed too. Minify CSS/JS files to shrink them (remove whitespace/comments). Evaluate whether all JS is needed immediately; defer or async non‑critical scripts so they don’t block HTML parsing. Critical CSS (inline the most important styles for above‑the‑fold content) can speed up first render. Be cautious with huge CSS frameworks or long chains of JS dependencies — load time adds up quickly.
• Render‑blocking and order: Scripts in the <head> without defer can block rendering (the browser waits until the script is loaded and executed). Place scripts near the end of the page or use defer so HTML parsing can continue. Stylesheets belong in the <head> to avoid flashes of unstyled content, but keep them small and few.
• Fonts and external sources: Custom web fonts look great, but can cause FOUT (Flash of Unstyled Text) or delay text rendering. Consider font-display: swap so text appears first with a system font. If possible, host external assets (like Google Fonts) locally to avoid extra DNS lookups and dependencies, or preconnect/preload them.

Perceived performance is about showing something useful as quickly as possible, even if the full page isn’t yet 100% loaded. Tactics include skeleton screens or loaders for late content, but ideally the most critical content loads immediately. Core Web Vitals such as Largest Contentful Paint (LCP) and First Input Delay (FID) measure how quickly key content appears and becomes interactive. They’re influenced by both front‑end optimizations and back‑end speed (TTFB).

In summary for the front‑end: optimize your assets, keep pages “light,” and prevent unnecessary elements from stealing the show before the essentials load. If the back‑end responds quickly but the browser still has to process 5 MB of images and scripts, the site will feel slow. It’s a partnership: make sure both server and front‑end are tuned to work smoothly together.

Conclusion: Checklist for a fast website

A fast website is the result of optimization across every link in the chain — from server to browser. Here’s a concise checklist of the tips and focus points we covered:

• DNS optimization: Use a fast DNS provider and avoid unnecessary DNS lookup delays. Aim for DNS resolution <100 ms.
• Server location and network: Choose a server close to your users and use a CDN for global coverage. Lower latency = faster first connection.
• Use modern protocols: Enable HTTPS with TLS 1.3 for minimal handshake overhead, and use HTTP/2 or HTTP/3 so resources load efficiently.
• Lower Time To First Byte (TTFB): Optimize your back‑end. A TTFB under 200 ms is ideal. Achieve this with caching, efficient code/database, and sufficient server resources.
• Relieve PHP workers: Prevent PHP processes from being constantly busy. Implement page caching so many requests never reach PHP. Keep your code lean; remove heavy plugins and schedule large tasks outside peak hours.
• Database tuning: Keep the database healthy. Remove clutter, add needed indexes, and use object caching (e.g., Redis) to absorb repeated queries.
• Use multi‑layer caching: Combine browser cache, CDN cache, server‑side page cache, object cache, and PHP opcode cache for optimal results. Caching is the key to scalability and speed.
• Front‑end optimization: Minimize assets — compress images, minify CSS/JS, load scripts async/deferred, and use lazy loading. Ensure critical content appears immediately (critical CSS, no unnecessary render blockers).
• Test and monitor: Use tools like Pingdom, GTmetrix or PageSpeed Insights to spot bottlenecks. Monitor both technical metrics (DNS, TTFB, etc.) and user experience (LCP, FID).
• Choose good hosting: Last but not least — a reliable managed hosting provider can handle many server‑level optimizations for you. Think built‑in caching layers, up‑to‑date software, strong infrastructure and support for performance issues. That lets you focus on the site itself while the host keeps the foundation fast and stable.

With these steps in mind, you can systematically improve website speed. Remember: speed is the sum of many components — small improvements across multiple areas can combine into a big impact. And a fast site isn’t just better for users (lower bounce rates, higher conversions), it’s also appreciated by search engines. Good luck optimizing — your users will notice.