What Is Web Hosting? The Complete Infrastructure Guide

What Web Hosting Actually Is (Not "File Storage")

Telling someone that web hosting is "where your website files are stored" is like telling someone that a restaurant is "where food is kept." It is accurate, and it misses everything that matters. Your website files sitting on a server do nothing on their own. Hosting is the operational infrastructure that takes those files and turns them into pages a browser can receive and render — and it does this millions of times a day, under load, while staying secure.

When someone visits your website, here is what actually happens at the infrastructure level. Your hosting server is a physical or virtual computer sitting inside a data center — a purpose-built facility with redundant power, climate control, and direct fiber connections to the internet backbone. That server runs an operating system, web server software, a PHP interpreter, and a database engine. It is connected to the internet with a dedicated port (typically 1 Gbps on shared hosting, up to 10 Gbps on dedicated servers). It is managed by the hosting provider's team, who keep it running, patched, and connected 24/7.

The hosting provider sells you access to some portion of that infrastructure. What you get — and how much of it is really yours — depends on the hosting type. On shared hosting, you get a fraction of a single server's resources shared with hundreds of other sites. On a dedicated server, you get the entire machine. Everything in between is a point on that spectrum.

The Seven Infrastructure Layers Every Host Provides

When you pay for hosting, you are paying for all of these simultaneously:

• Compute (CPU): the processor cycles that execute PHP, run database queries, compress files, and generate HTML responses. PHP execution is CPU-bound. A slow CPU means slow pages.
• Memory (RAM): the working memory available to PHP processes, the database engine, and the operating system. Low RAM means PHP processes get killed mid-execution, causing 500 errors.
• Storage: the disk that holds your WordPress files, database, and uploaded media. Storage speed (HDD vs SSD vs NVMe) affects how fast files are read during each request.
• Disk I/O: how fast data can be read from and written to the disk. High-traffic sites can saturate disk I/O even when CPU and RAM are fine, causing random slowdowns and database lock timeouts.
• Network: the connection between the server and the internet. Port speed determines maximum throughput. Shared hosting connects you to the internet via a shared 1 Gbps port. Data travels over this connection from server to every visitor.
• IP Address and DNS: the server's unique address on the internet, and the DNS configuration that routes your domain name to that address. DNS is the phonebook that translates "example.com" into "198.51.100.42".
• Web Server Software: the application layer that receives HTTP requests, applies rules (.htaccess, rewrites, redirects), passes PHP requests to the PHP interpreter, and sends the response back. Apache, Nginx, and LiteSpeed are the three dominant options — and they behave very differently under load.

The Full Website Request Journey: What Happens the Millisecond You Press Enter

This single section explains more about web hosting than most people learn in years of running websites. The request journey is not a background detail — it is the mechanism through which hosting quality translates into visitor experience. Every hosting company's marketing claim (fast servers, low TTFB, 99.9% uptime) is a claim about a specific step in this journey. Understanding the journey lets you evaluate those claims accurately.

Here is every step a page request takes, from the moment a visitor types your URL and presses Enter, to the moment the page appears in their browser:

Step 1: DNS Lookup

The visitor's browser does not know the IP address of your server. It only knows your domain name. The browser first checks its local cache (if it has visited recently). If not cached, it queries a recursive DNS resolver (usually the visitor's ISP or a public resolver like Cloudflare's 1.1.1.1). That resolver walks the DNS hierarchy: root nameservers identify the TLD authority (.com), the TLD nameserver identifies your domain's nameserver, and your nameserver returns the A record with your server's IP address. The whole process takes 10-200ms depending on whether results are cached along the way. For a deeper breakdown of every DNS record type, see the DNS records guide.

Step 2: TCP Connection

With the IP address resolved, the browser opens a TCP connection to your server. This is a three-way handshake: the browser sends a SYN packet, the server responds with SYN-ACK, and the browser confirms with ACK. This takes one full round trip — which is why server geographic location matters. A visitor in Sydney connecting to a server in London adds ~250ms for this single handshake. HTTP/2 and HTTP/3 reduce the total number of round trips required, but the physics of distance are unavoidable.

Step 3: TLS Handshake

Because your site uses HTTPS, the browser and server now negotiate an encrypted connection. They agree on a cipher suite, exchange keys, and authenticate the server's SSL certificate. TLS 1.3 (the current standard) completes this in a single round trip, down from TLS 1.2's two. The hosting provider is responsible for maintaining valid SSL certificates and supporting current TLS versions — a misconfigured or expired certificate here aborts the entire connection before any page is served.

Step 4: HTTP Request Transmission

The browser sends the HTTP request (GET /page-name HTTP/2) with headers including the host domain, accepted content types, and cookie data. This is fast — a few milliseconds over an established connection.

Step 5: Server Processing

This is where hosting quality has the largest direct impact. The web server software receives the request. For a static HTML file, it reads the file from disk and responds immediately. For a WordPress page, it does something more complex: it hands the request to PHP, which boots a WordPress instance, loads wp-config.php to get database credentials, and begins executing the page template. This is the step that separates a well-configured host from a slow one. On a server with limited CPU, throttled processes, or an old PHP version, this step can take 1-2 seconds even with no traffic. Good hosting makes it take 50-200ms.

Step 6: Database Query Execution

WordPress makes database calls during PHP execution to retrieve post content, navigation menus, widget settings, plugin data, and more. A default WordPress install with a moderately complex theme and common plugins can execute 40-100 MySQL queries per page load. The database engine (MySQL or MariaDB) executes these queries against tables on disk, returns results to PHP, and PHP builds the final HTML. Uncached, this is the single biggest variable in page response time. A slow query on an unindexed table on a busy shared host can dominate total TTFB. A page cache eliminates this step entirely for most requests.

Step 7: Browser Rendering

The server sends the HTML document to the browser. The browser parses it, requests additional assets (CSS, JS, images), and renders the visual page. This step happens on the visitor's device and is outside the hosting provider's control — except insofar as the server delivers those assets quickly. CDNs reduce this step's duration by placing assets on edge servers close to the visitor, cutting the time to transfer large image and script files.

Server Resources Explained: CPU, RAM, I/O, and Why They Are Not Equal

Hosting plans advertise storage and bandwidth. The specs that actually govern your site's performance are never listed in the headline features: CPU allocation, RAM limits, disk I/O throughput, inode count, and concurrent process limits. These five resources determine whether your site handles 100 simultaneous visitors or collapses under 10. I have seen sites on premium shared hosting plans that performed worse than a basic VPS because the host's resource limits were tighter than the plan's price suggested.

CPU: The Processing Engine

Every PHP execution, every database query, every image compression operation, and every compression algorithm your server runs consumes CPU cycles. On shared hosting, you do not get a dedicated CPU core. You get a burst allocation — permission to use up to some fraction of a core for short periods — capped by a scheduler that prevents any single account from dominating the server. When you hit the CPU ceiling, your PHP processes queue up waiting for a turn. Pages slow down. Under sustained load, they time out.

On a VPS, you get guaranteed vCPU allocation. Your processes are not competing with 300 neighbors for CPU time. The difference is not just speed — it is consistency. A shared host can serve your page in 200ms at 9 AM and 2,000ms at 2 PM when a neighbor runs a cron job. A VPS serves it in 200ms both times.

CPU quality matters too. Not all vCPUs are equal. A vCPU on a server running a 2015-era Intel Xeon E5 performs 3-4x worse per core than a vCPU on a 2023 AMD EPYC 9474F. The CPU PassMark guide explains how to compare processors across hosting generations.

RAM: Working Memory for Your Site

PHP requires memory to run. A typical WordPress PHP process uses 32-128 MB of RAM per request. When multiple visitors hit the site simultaneously, multiple PHP processes run in parallel, each consuming that memory. The server's total RAM is divided among all running processes. On shared hosting, if the server runs out of memory, your PHP processes are killed with a 500 error or a "memory exhausted" message. Most shared hosts cap per-account RAM at 256 MB to 1 GB with fair-use enforcement.

The MySQL database engine also consumes RAM — a lot of it. InnoDB's buffer pool (the in-memory cache of frequently accessed database pages) dramatically reduces disk reads. A well-configured database server with adequate RAM serves most queries from memory. A RAM-starved server reads from disk for every query — which is 10-100x slower. On managed VPS plans, the host configures this correctly. On shared hosting, the buffer pool is shared with every database on the server.

Disk I/O: The Often-Forgotten Bottleneck

Disk I/O is the throughput at which data is read from and written to storage. It matters for two reasons. First, PHP reads files on every execution — theme templates, plugin files, WordPress core files. Second, the database reads data blocks from disk for every uncached query. On a busy shared host with HDD or low-quality SSD storage, disk I/O contention among hundreds of accounts creates random slowdowns that are nearly impossible to diagnose without server-level monitoring.

NVMe storage dramatically improves this layer. NVMe drives deliver sequential read speeds of 3,000-7,000 MB/s versus SATA SSD at 500-600 MB/s and HDD at 100-150 MB/s. The practical improvement for a database-heavy WordPress site is real — queries that take 40ms on SATA SSD take 8ms on NVMe. But NVMe alone does not make a slow server fast if CPU or RAM is the bottleneck. It helps the I/O layer specifically.

Inode Limits: The Hidden Filesystem Constraint

An inode is a filesystem metadata entry for every file and directory on your account. Every WordPress core file, plugin file, theme file, uploaded image, and log file counts as one inode. Most shared hosting plans cap inodes at 100,000 to 400,000 per account. A standard WordPress install with 20 plugins and a growing media library can approach 150,000 inodes. A WooCommerce store with product images and plugin cache files can exceed 400,000 inodes. When you hit the inode cap, you cannot create new files — even if you have gigabytes of free storage. The inode limit guide covers this constraint in full detail.

Concurrent Processes: How Many Visitors Can Be Served Simultaneously

PHP-FPM (the process manager used by most modern hosts) runs a pool of PHP worker processes. Each active visitor request occupies one worker. If all workers are busy, additional requests queue. If the queue fills, visitors get a 503 error. On shared hosting, you typically get 20-40 PHP workers. That sounds like a lot until you realize a slow page (800ms server response) holds its worker occupied for 800ms, meaning 40 workers can only serve 50 pages per second — 3,000 pages per minute at full capacity under ideal conditions. In practice, much less.

Hosting Types Compared: Shared, VPS, Cloud, Dedicated, Managed

There are five main hosting categories and one important subtype. The marketing descriptions of each are accurate as far as they go. The parts that are not explained in the marketing — the actual limitations, the realistic use cases, the scaling thresholds — are what this section covers.

Shared Hosting: What You Get and What You Give Up

Shared hosting is the entry point for most websites, and for good reason: it is inexpensive, fully managed, and requires zero server administration knowledge. A shared hosting account gives you cPanel or a similar control panel, one-click WordPress installation, email accounts, and enough resources to run a small-to-medium site without issue. The tradeoff is resource competition.

On a modern shared host with CloudLinux installed, each account is isolated at the operating system level using CageFS (filesystem namespaces) and LVE (per-account resource limits). This prevents a compromised or runaway account from affecting others — but it also means there is a hard ceiling on what your account can consume. When you hit that ceiling, your site slows down or returns errors, regardless of what the hosting plan page says about "unlimited" resources.

Shared hosting makes economic sense for sites under approximately 50,000 monthly visitors with simple page structures. Beyond that threshold — especially for WooCommerce stores — the CPU and concurrent process limits start to show under real traffic. The decision to move up is usually triggered by seeing consistent PHP errors in logs or TTFB climbing above 800ms under normal load.

VPS: What Changes When You Get Your Own Resources

A Virtual Private Server uses hypervisor technology (KVM, VMware, Hyper-V) to divide a physical server into isolated virtual machines. Each VM has its own operating system instance, guaranteed CPU allocation, and dedicated RAM. There is no competition for resources with other accounts. The noisy-neighbor problem disappears because the hypervisor enforces isolation at the hardware level.

What does not change: you now own the operating system. On an unmanaged VPS, you are responsible for installing software, applying security patches, configuring PHP, managing firewalls, and troubleshooting server errors. This requires Linux sysadmin knowledge that most site owners do not have. A managed VPS resolves this by having the provider handle server administration while you retain the resource benefits. ScalaHosting with SPanel and Cloudways are the two providers with the most coherent managed VPS offerings for WordPress.

Cloud Hosting: Scalability at a Cost

Cloud hosting differs from VPS in one critical way: resources can scale dynamically. A traditional VPS has a fixed CPU and RAM ceiling. Cloud infrastructure (AWS, Google Cloud, DigitalOcean, Cloudways on top of these) allows resources to scale up when traffic spikes and scale down when it subsides — in theory automatically, in practice often requiring manual configuration or auto-scaling rules.

Cloud hosting is not inherently faster than a VPS at any given resource level. The performance characteristics depend entirely on the VM size, the underlying hardware generation, and the configuration. Where cloud wins is reliability: data is typically replicated across nodes so a single hardware failure does not cause an outage, and geo-distributed deployment is achievable without physical infrastructure.

Dedicated Servers: Full Control, Full Responsibility

A dedicated server is a physical machine in a data center leased entirely to you. Every CPU core, every gigabyte of RAM, every I/O operation is yours. There is no hypervisor overhead, no virtualization tax. For workloads that require sustained high CPU throughput — large WooCommerce catalogs, high-volume media processing, database clusters — dedicated hardware provides performance that no shared environment can match at the same price.

The tradeoff is management overhead. Even managed dedicated server plans require more operational responsibility than shared or managed VPS hosting. Hardware failure means a server rebuild or migration. A broken update can take the entire machine offline. Dedicated servers are appropriate for established operations with technical staff or a managed services contract — not for sites that have simply outgrown shared hosting.

Resource Allocation: The Hidden Specs Nobody Advertises

Hosting plan pages show storage, bandwidth, and number of sites. None of these are the resources that determine actual performance. The resources that matter are CPU allocation, RAM per process, disk I/O limits, inode caps, and concurrent process counts. These are almost never published in plan comparisons, and the gaps between providers are enormous.

I have tested shared hosting accounts from eight different providers with the same WordPress theme and plugin set. The fastest shared host delivered TTFB of 180ms. The slowest delivered 1,400ms. Same WordPress configuration, same content. The only variable was server resource allocation. The faster provider had newer CPU hardware, more generous PHP worker counts, and LiteSpeed web server with page cache enabled by default. The slower provider had legacy Apache on older hardware with conservative resource limits.

How Resource Limits Are Enforced on Shared Hosting

On shared hosting with CloudLinux (which covers the majority of quality shared hosts), resource limits are enforced at the kernel level using LVE (Lightweight Virtual Environment). Each cPanel account has a resource container with hard limits on CPU, RAM, I/O, inodes, and concurrent processes. When your site hits a limit, the kernel throttles the offending process. This is why shared hosting performance feels unpredictable: you are fine until a limit is hit, and then suddenly pages queue and slow down.

The specific limits vary by host and plan. Entry-level shared plans at budget hosts might cap at 25% of a CPU core and 512 MB RAM. Better shared plans on quality hosts might allow 100% of a core (temporarily) and 1-2 GB RAM. You generally cannot find this information in plan marketing — you need to check it in the LVE Manager inside cPanel if your host provides it, or ask support directly.

The Concurrent Process Problem

This is the resource limit most responsible for traffic-induced failures on shared hosting. PHP-FPM manages a pool of worker processes. Each worker handles one request at a time. A worker that takes 500ms per page request can handle 120 requests per minute. If your site has 40 workers allocated and each page takes 500ms, your absolute maximum throughput is 4,800 pages per minute — but in practice, with no caching, under real traffic with varying request durations, you will start seeing queuing and 503 errors much earlier than that mathematical limit.

Page caching bypasses this entirely for cached pages. A cached page is served as a static file by the web server without touching PHP or the database. It can be served in 5-20ms instead of 500ms. This is why enabling page caching on shared hosting is not optional for sites with any meaningful traffic — it is the difference between staying online and returning 503 errors during a traffic spike.

The Performance Stack: CDN, Cache, Web Server, SSL, and TTFB

Site speed is not a single setting. It is the sum of six distinct layers, each controlled by different parties, each improvable independently. Most site owners optimize one or two layers and wonder why the site is still slow. The hosting provider controls three of these layers. You control two. One is shared. Knowing which is which prevents wasted effort.

CDN: The Geographic Speed Multiplier

A CDN (Content Delivery Network) places copies of your static assets — images, CSS, JavaScript, often HTML pages — on servers distributed around the world. When a visitor requests one of these assets, they receive it from the nearest CDN edge node rather than from your origin server. A visitor in Tokyo receiving assets from a CDN node in Tokyo gets them in 15ms. The same visitor without a CDN, fetching from a server in New York, waits 200ms for physics alone. CDNs reduce latency for international visitors and offload bandwidth from your origin server.

For dynamic content (page HTML that changes per user or per request), a CDN cannot cache unless you configure it to. WooCommerce cart pages, account pages, and checkout flows are examples of content that must be fetched from the origin server every time. A CDN improves the assets supporting those pages — CSS, images — but not the HTML itself.

Cache Layers: The Stack That Transforms Performance

There are four distinct caching layers in a WordPress hosting environment, and they stack on top of each other:

• CDN edge cache: caches full pages or assets at edge nodes. When hit, the request never reaches your server.
• Page cache: stores fully rendered HTML on the server. When hit, PHP and the database are bypassed entirely. Can reduce TTFB from 800ms to 50ms.
• PHP OPcache: caches compiled PHP bytecode in server memory. Eliminates the PHP compile step on every request — significant on servers with many PHP files.
• Object cache (Redis / Memcached): stores the results of expensive database queries in memory. When hit, reduces database load and speeds dynamic page generation.

A site with all four layers configured correctly can serve cached pages in under 100ms TTFB even on modest hardware. The same site with no caching might take 1,500ms on the same hardware. Caching is the highest-leverage performance improvement available for any WordPress site.

Web Server Software: The Request Handler

The web server (Apache, Nginx, LiteSpeed) handles every incoming HTTP request. It applies rewrite rules, serves static files, passes PHP requests to PHP-FPM, and manages HTTP/2 connections. The choice of web server has measurable performance implications. LiteSpeed, used by many quality shared hosts, includes a built-in page cache (LSCache) that performs as well as separate caching plugins — and can serve cached pages without involving PHP at all. Nginx is highly efficient at serving static files. Apache with .htaccess is the most compatible but the least efficient at high concurrency.

SSL/TLS: Security With a Performance Profile

SSL certificates encrypt traffic between server and visitor. They are non-negotiable in 2026 — browsers display security warnings for HTTP sites and Google uses HTTPS as a ranking signal. The performance overhead of SSL depends on the protocol version. TLS 1.3 completes the handshake in one round trip. TLS 1.2 requires two. Session resumption (where a returning visitor reuses a previous TLS session) reduces this to near-zero. A well-configured host enables TLS 1.3 by default. Let's Encrypt provides free certificates that auto-renew — the only reason to pay for a certificate in 2026 is for OV or EV validation for high-trust commercial sites.

TTFB: The Master Metric

Time to First Byte (TTFB) measures the total time from the start of the HTTP request to the first byte of the response arriving at the browser. It includes DNS lookup, TCP connection, TLS handshake, and server processing time. TTFB is the clearest single indicator of hosting infrastructure quality. Google's Core Web Vitals guidelines target TTFB under 800ms; competitive sites target under 200ms. A consistently high TTFB that does not improve after caching is enabled points to raw server resource limitations that require a hosting upgrade to resolve.

Beginner Hosting Myths That Cost People Money

Hosting marketing has produced a specific set of misconceptions that lead site owners to make bad decisions — staying on a plan too long, upgrading when they should not, or trusting claims that are technically true but operationally meaningless. These six myths are the most expensive.

How to Choose a Hosting Type: A Decision Framework by Site Type

The right hosting type is determined by three variables: your site's resource consumption, your traffic level, and your tolerance for managing server infrastructure. This is not about finding the "best host." It is about matching your current and projected requirements to the right infrastructure tier — and having a concrete signal for when to move up.

The Framework

Start with site type. Then apply the traffic and complexity modifiers below. If two factors point to different tiers, use the higher one.

The Concrete Upgrade Signals

Stop guessing when to upgrade. Watch for these specific signals in your server data:

• PHP memory exhaustion errors in your error log (PHP Fatal error: Allowed memory size exhausted). This is the server telling you it cannot allocate enough RAM for your PHP processes.
• CPU throttling notices in cPanel's LVE Manager or Resource Usage (if your host provides it). Frequent CPU fault entries mean your site is regularly hitting the CPU ceiling.
• TTFB above 800ms measured after confirming page cache is enabled and working. If cache is hitting and TTFB is still 800ms+, you have exhausted what caching can do on your current hardware.
• 503 errors under normal traffic. This indicates PHP worker exhaustion — all process slots are occupied and new requests are being refused.
• Database connection limit errors (Too many connections). Shared hosting database servers cap concurrent connections per account. Hitting this limit during peak hours is a sign your database load needs dedicated resources.

Data Centers and Uptime: What 99.9% Actually Means

Every hosting provider claims excellent uptime. The numbers look similar across all providers in marketing. The differences emerge when you read the SLA definitions, measure independently, and understand what the data center infrastructure behind those promises actually looks like.

The Uptime Math Nobody Shows You

Uptime percentages convert to downtime allowances that look very different in concrete hours:

• 99% uptime = 87.6 hours per year (3.65 days)
• 99.9% uptime = 8.76 hours per year (about 9 hours)
• 99.99% uptime = 52.6 minutes per year
• 99.999% uptime = 5.26 minutes per year

Most shared hosting providers advertise 99.9% uptime. That is 8.76 hours of allowed downtime per year — and the SLA allows the host to average this over a rolling period, exclude planned maintenance windows, and require you to file a ticket to claim any credit. The credit is also typically account credit, not cash — and it compensates you for a fraction of your hosting fee, not for revenue lost during the outage.

For a detailed breakdown of what uptime guarantees actually cover and how to monitor independently, see the uptime and downtime guide.

What Data Center Infrastructure Determines Uptime

Uptime claims are backed (or not backed) by the physical infrastructure in the host's data center. The Uptime Institute's Tier classification system defines four tiers by redundancy level:

• Tier I: no redundancy. A single UPS failure, network failure, or HVAC failure takes the facility offline. Allows 28.8 hours of downtime per year.
• Tier II: some redundancy in power and cooling. Allows 22 hours of downtime per year.
• Tier III: N+1 redundancy — every component has at least one backup. Allows 1.6 hours of downtime per year. This is the minimum tier for serious hosting infrastructure.
• Tier IV: fully fault-tolerant — 2N+1 redundancy. Allows 26.3 minutes of downtime per year. Used for mission-critical enterprise hosting.

Budget shared hosts may operate in Tier I or Tier II facilities. Quality managed hosting and enterprise-grade infrastructure typically occupies Tier III certified data centers. The tier affects everything from power redundancy (how many UPS systems and generators) to network redundancy (how many upstream providers) to cooling redundancy (how many CRAC units).

Domains, DNS, and How Your Name Points to a Server

Hosting and domain registration are separate services that work together through DNS. Understanding this separation prevents confusion during migrations and explains why "pointing your domain to your host" is a specific, technical action — not just a setting you click once and forget.

The Separation That Confuses Everyone

Your domain name (example.com) is registered through a domain registrar (Namecheap, GoDaddy, Google Domains). You pay for the right to use that name. The registrar holds records of your ownership and sets the authoritative nameservers for your domain. Nameservers are the DNS servers that actually answer questions about your domain — like "what is the IP address for example.com?"

When you sign up for hosting, the hosting provider gives you a server IP address and, usually, their nameservers. You update your domain's nameserver setting at the registrar to point to the host's nameservers. Once propagated, any DNS query for your domain goes to the host's nameservers, which return the correct IP address for your server. The chain is: registrar (who owns the domain) → nameservers (who answers DNS queries) → IP address (where the server actually is).

DNS Propagation: Why Changes Are Not Instant

DNS changes take time to propagate globally because DNS resolvers around the world cache records for a period defined by the TTL (Time to Live) value on each record. A 24-hour TTL means cached results are kept for up to 24 hours before resolvers re-query for updated information. During this window, some visitors reach the old server, others reach the new one, depending on which resolver they use.

This is why DNS TTL management matters during hosting migrations. Reducing the TTL on your A record to 300 seconds (5 minutes) 24-48 hours before a migration means most cached records expire quickly after the switch. After the migration is stable, the TTL can be restored to its normal value. For the complete set of DNS record types (A, AAAA, CNAME, MX, TXT, NS) and when to use each, the DNS records guide covers every type with practical examples.

How Hosting Migrations Actually Work

A hosting migration has four phases: set up the new environment, copy files and database, test on the new server using /etc/hosts or a temporary staging URL, then update DNS to point to the new server. The risk window is the DNS propagation period, during which some visitors reach the old server. For a WooCommerce store, orders placed during this window may land on either server. Planning the cutover for low-traffic hours (typically 2-4 AM in your primary market) and reducing TTL beforehand minimizes this risk.

Security and Backups: What the Host Handles vs What You Handle

Most hosting security incidents happen at the application layer — a vulnerable plugin, a weak password, outdated WordPress core. Most hosting marketing implies the host handles security comprehensively. The reality is a division of responsibility that is important to understand before assuming you are covered.

What the Host Is Responsible For

A reputable host handles: server-level firewall rules blocking known attack sources, DDoS mitigation at the network level, shared hosting isolation (CloudLinux CageFS preventing cross-account compromise), SSL certificate provisioning (Let's Encrypt AutoSSL), server OS patching and security updates, and data center physical security. These are infrastructure-level protections that operate below your application. You cannot configure them, and you do not need to — they are maintained by the host.

For common web-layer attack types (SQL injection, XSS, brute force, DDoS) and the exact division of responsibility between host infrastructure and application-level defense, see the web hosting security threats guide.

What You Are Responsible For

Everything at the application layer: WordPress core updates, plugin updates, theme updates, admin account passwords, file permissions, database user privileges, and security plugin configuration. A host providing excellent infrastructure-level security cannot protect a site running a WordPress plugin with a known, unpatched remote code execution vulnerability. The application layer is yours.

Backups: The Shared Responsibility Nobody Explains

Hosting providers create backups of their servers regularly. These backups exist to help the host recover from infrastructure-level failures — a RAID failure, a datacenter incident. They are not designed as a granular restore service for individual account files. The host's daily backup has a retention window (typically 7-30 days rolling), lives on the same infrastructure as the live site, and is inaccessible if your account is suspended for a policy violation.

An independent backup strategy stores copies of your site on infrastructure you control — a cloud storage bucket on a separate provider. This copy survives account suspension, datacenter incidents, and ransomware attacks that might compromise the host's accessible backup storage. A proper strategy follows the 3-2-1 rule: three copies, two different storage providers, one offsite.

Where to Go Next

This guide has covered what hosting actually is at the infrastructure level. The next step depends on which layer is most relevant to your current situation.

If you are evaluating hosting types and trying to decide what to buy, the shared hosting vs VPS comparison gives you a buying-intent breakdown with specific provider recommendations. If you are trying to improve performance on your current hosting, start with TTFB optimization — it is the master performance metric and the guide walks through every contributing layer. If you are building an understanding of the DNS infrastructure that connects your domain to your server, the nameservers guide and DNS records guide cover the full resolution chain.

For the hosting infrastructure underpinning shared hosting specifically — how CloudLinux isolates accounts and enforces resource limits — the CloudLinux guide explains exactly how the isolation and per-account limits work in practice. For the server hardware behind performance claims — CPU generations, NVMe vs SSD, PassMark benchmarks — the server hardware guide and PassMark CPU rankings guide provide the data needed to evaluate hosting specs honestly.