Module 1 · 1.2

English

Nederlands English Deutsch Français Español

Under the bonnet: web server, PHP and database

Module 1: How WordPress works · Reading time: 8 minutes

Learning objective: After this lesson you can explain, step by step, how a page request to WordPress becomes an HTML page, and where a cache shortens that path.

Key concepts: web server (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, query, index.php, template hierarchy, dynamic vs static, TTFB

A static and a dynamic page

On a static website, every page exists as a ready-made file on the server. The web server picks up the file and sends it off. That's fast and simple, but every change means a new file.

WordPress is dynamic: the page only exists the moment someone asks for it. There is no file called contact.html. There is a piece of text in the database, a theme with templates, and a stack of PHP code that combines the two. That gives you convenience (you edit the text in your browser), but it costs computing work on every visit. Once you understand that work, you'll also understand later why a website is slow, why caching makes such a difference, and why a PHP upgrade can break something.

The journey of a page request

Say a visitor opens https://example.com/contact/. Here's what happens:

DNS: the browser looks up the IP address of example.com (see the DNS course). It makes a secure connection to that address.
Web server: a web server runs on the server, for example LiteSpeed, Apache or nginx. It receives the request. If a real file or folder with that name exists (an image, a stylesheet), it sends that directly. If not, the rule from .htaccess (for LiteSpeed and Apache) or from the nginx configuration applies: "hand everything that doesn't exist to index.php".
PHP: index.php is a PHP file. The web server has it executed by PHP, the programming language WordPress is written in. PHP first loads wp-config.php (the settings, including the database details), then the rest of WordPress, then all active plugins and the active theme.
Database: WordPress works out which content belongs to /contact/ and asks the database (MariaDB or MySQL) questions: which Page has the slug contact, what are the site's settings, which menu belongs to it? Such a question is called a query. A simple page can easily cost dozens of queries; with plugins, that can run into the hundreds.
Theme: WordPress chooses which theme template formats the page. This follows the template hierarchy: for a Page with slug contact, WordPress first looks for a template page-contact, then page-<id> (the page's number), then page, then singular, and finally index. The first one that exists wins.
HTML back: the result is an HTML page that PHP hands to the web server, and the web server hands to the browser.
The browser reads the HTML and then fetches the stylesheets, scripts, fonts and images. Those are ordinary files, so they come straight from the web server (or from a cache).

Between step 2 and step 6 lies the time the server needs to build the page. You see this reflected as TTFB (time to first byte): the time between the request and the first byte of the response. On a well-set-up website, that's comfortably under a second. In module 6 you'll measure this yourself.

Why every plugin counts

In step 3, all active plugins are loaded, on every request. Even if that plugin does nothing on this particular page. A plugin for a photo gallery is therefore also loaded when someone opens your contact page. Every plugin can run extra queries, load extra code and add extra scripts to the page.

That explains two things you'll come across more often in this course:

Fewer plugins is usually faster. Not because the number itself matters, but because every plugin can do work on every request.
One broken plugin can bring down the whole website. If something goes wrong in step 3 (for example, a plugin that doesn't work with the new PHP version), PHP never reaches step 6. The visitor gets a blank page or the message "There has been a critical error on this website" (lesson 5.4).

Where PHP and the database come from

PHP and the database run on your hosting provider's server. You usually choose the PHP version yourself in the control panel (in DirectAdmin this is called Select PHP version, see lesson 8.4). You create the database during installation; the installer often does this for you (lesson 2.2).

A few things to remember:

PHP version: every new PHP version is faster and more secure, but old code can break on it. wordpress.org currently recommends PHP 8.3 or higher (as of November 2026).
Database: wordpress.org recommends MariaDB 10.11 or higher, or MySQL 8.0 or higher. MariaDB is a fork of MySQL; for WordPress it makes no difference.
The database is usually on the same server (DB_HOST is then localhost). With larger hosting setups, it can sit on a separate server.

Cache: shortening the path

If a hundred visitors request the same contact page, WordPress builds it a hundred times over without a cache. The same queries, the same template, the same HTML every time. A page cache stores the HTML after the first time. The next visitor gets the stored version: steps 3 through 6 are skipped.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

That's why caching gives the biggest speed gain (lesson 6.2). It also explains a common source of confusion: "I've changed the text, but I still see the old version." You're then getting a stored version; after clearing the cache, you'll see the new one.

Not everything can come from a cache. A logged-in administrator, a shopping cart, or a checkout page is different for every visitor. A good caching plugin skips those.

Headers: what the server tells you

Every response from a web server starts with headers, before the HTML. You don't see these on the page, but you do see them in your browser's developer tools (F12, Network tab, click the first request). An example:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

server tells you which web server is responding.
link with wp-json gives away that it's WordPress.
x-litespeed-cache: hit means this page came from the LiteSpeed cache. Other caches use different names, such as x-cache: HIT or cf-cache-status: HIT for Cloudflare.

You don't need to memorise these lines. But if you can read them, you can find many problems yourself.

Summary

WordPress builds every page at the moment of the request: web server, PHP, plugins, database, theme, HTML.
All active plugins are loaded on every request; one broken plugin can stop the whole website.
The template hierarchy determines which theme template formats a page.
A page cache skips the computing work by serving stored HTML. Logged-in users and shopping carts don't belong in that cache.
A response's headers tell you which web server is answering and whether the page came from a cache.

Quiz

Exercise

Exercise A1.2: Read your website's headers. Open your own website (or wordpress.org) with your browser's developer tools (F12, Network tab, refresh the page, click the first request). Fill in which web server is listed in the server header (or "none" if it's missing) and whether there's a header saying the page came from a cache (which name and which value). The program requests the same page and compares.

Cookies at WebOké

Cookie settings

Necessary

Marketing