Web Server Explained: What It Does and How to Size One

Last reviewed: 29 August 2026.

A web server is the hardware and software layer that receives web requests and returns website content over HTTP. According to MDN web-server documentation, a missing requested document can produce a 404 response. Size the host from measured concurrency, response latency, cache behaviour and application dependencies rather than from page count alone.

A web server is a request-serving role, not a promise about one specific machine size. Measure the traffic path first, then choose CPU, memory, storage and network capacity around the bottleneck you can actually observe.

What does a web server actually do?

At the simplest layer, a web server accepts an HTTP request, maps that request to content and returns a response. Static files can be served directly, while dynamic requests may be handed to application code before a response comes back. AWS's web-server and application-server explainer makes that division useful for architecture discussions: the web tier focuses on delivering content, while application logic can sit behind it.

That distinction matters when you troubleshoot. A slow page does not automatically mean the web server needs more RAM. The delay could be upstream application work, a database query, object storage, an external API, TLS setup, cache misses or a congested network path. Start with request traces and server metrics so the component receiving the request is not blamed for work occurring elsewhere.

How is a web server different from an application server?

A web server is normally the front door for HTTP traffic. An application server is the runtime layer that executes business rules, generates dynamic responses and integrates with databases, queues or third-party services. Some products combine both roles, so the labels are architectural rather than guarantees that two separate machines exist.

For a WordPress site, ecommerce store or SaaS application, the useful question is where work happens during a request. If static assets are fast but checkout or dashboard requests are slow, inspect the dynamic path. If every response slows when connections rise, inspect the front-end worker model, TLS overhead, rate limits and network saturation. The right capacity change depends on which tier is constrained.

How should you size a web server?

Begin with a repeatable workload. Record normal request rate, peak request rate, response-time distribution, CPU utilisation, memory headroom, disk latency and network throughput. Then reproduce a realistic peak in a staging environment. The goal is not to chase a synthetic maximum; it is to learn which resource hits its limit first and how much headroom remains before user-facing latency deteriorates.

Separate capacity from resilience. A larger single host may absorb a traffic burst, but it remains one failure domain unless the wider design adds redundancy. Horizontal scaling can distribute requests, but it also creates requirements around sessions, shared storage, deployment consistency and database capacity. Choose the smallest architecture that meets the workload and recovery requirements you can defend with measurements.

Which HTTP responses help diagnose the tier?

The IANA HTTP status registry lists 200 as OK and 404 as Not Found. Those codes are useful observations, but they are not a complete diagnosis. A normal success response can still be slow, and a missing-resource response may be caused by routing, deployment or content configuration rather than hardware capacity.

Use status distribution beside latency and upstream timing. When errors cluster around a deployment, compare routes and files.

When failures appear only under burst traffic, inspect connection pools, workers and upstream timeouts. When the origin is healthy but users are slow, include DNS, proxy, CDN and network path measurements. This keeps the buying decision tied to the actual fault domain.

What should you ask a hosting provider before ordering?

• Which CPU model and allocation model will serve the workload?
• How much memory headroom can be added without migration?
• What storage medium and I/O limits apply?
• What network port, transfer policy and DDoS scope apply to the service?
• How are backups, snapshots and restore requests handled?
• Can you move from VPS to bare metal without redesigning DNS and deployment?

For a broader compute decision, compare this role with the planned application server explainer. For ecommerce-specific planning, continue to the festive WooCommerce capacity plan. Those articles treat the web tier as one part of a service path rather than as a standalone performance guarantee.

How should you diagnose pressure in the request-serving tier?

Start by locating the delay before changing capacity. Separate connection handling, static asset delivery, application hand-off and upstream dependency time so the team can see where requests are waiting. A busy request-serving tier can look like an application problem when worker slots are exhausted, while a slow application can make the front tier appear saturated because connections remain open longer. Compare request latency with worker utilisation, queueing, error patterns and upstream response time. The objective is to identify the constrained stage rather than raising every limit at once.

Use the same request path for troubleshooting that real users take. Check whether cacheable assets are actually being served from the intended layer, whether dynamic routes are reaching the correct upstream, and whether timeouts align with application behaviour. Review recent configuration or deployment changes alongside traffic changes. When a fault is intermittent, capture enough request context to distinguish client disconnects, origin failures and gateway failures without logging sensitive payloads. A diagnosis that names the failing layer gives you a safer remediation than a generic instruction to “add more server”.

• Confirm which layer accepted the request and which upstream handled it.
• Compare healthy and degraded request paths rather than relying on average latency alone.
• Check queueing, worker pressure and upstream wait time before increasing concurrency.
• Verify caching and compression behaviour on the routes where they are expected.
• Record the change that fixes the bottleneck so the next capacity review starts with evidence.

Frequently asked questions

Is a web server hardware or software?

The term can mean the machine, the HTTP-serving software, or the two working together. For hosting decisions, separate software behaviour from the CPU, memory, storage and network resources underneath it.

Does every dynamic website need a separate application server?

No. Many modern stacks combine web-serving and application functions in one process or one virtual machine. Separate tiers become useful when scaling, security boundaries or deployment ownership justify them.

What should I monitor on a web server?

Track request rate, latency, error patterns, CPU pressure, memory pressure, connection saturation and storage or filesystem constraints. Use those signals to decide whether tuning, caching, horizontal scaling or a larger host is appropriate.

What is the practical takeaway?

Choose a web server by workload evidence. Confirm what the front-end software serves directly, what it forwards, which resource saturates first, and what recovery design surrounds the host. That process produces a defensible VPS, dedicated-server or multi-node decision without pretending that one generic RAM figure fits every website. Keep the baseline and retest it after material application changes so the sizing decision remains tied to the workload you actually run.