Understanding “Server-Side” and “Client-Side” in WordPress
If you’re looking to understand the inner workings of WordPress, one of the most important things you’ll need to understand is the distinction between server-side and client-side languages, environments, and processes.
It’s also embedded deeply in any discussion of the Loop and the other processes WordPress uses to generate webpages.
More generally, you simply can’t understand WordPress without it. So let’s take a look!
I made a big diagram in PowerPoint and had a lot of fun doing it; I’ll be dropping that on you in a minute. But before that, we’ll need a few key pieces of terminology, which I’ve stripped down to their bare essentials:
- User: a person who wants to view and interact with webpages using an internet-capable device, like a computer or smartphone.
- Client: the User’s internet browser, running on his or her device.
- Server: the computer—which could be anywhere in the world—where the desired website is hosted (stored).
- Local: stored on, happening in, or otherwise pertaining to the environment of the User’s device.
- Remote: stored on, happening in, or otherwise pertaining to the environment of the server.
Also, for a refresher, we’ll be looking at the role played by each of the following languages that constitute the core of WordPress:
- HTML: What web browsers read to turn text into fully formatted webpages.
- CSS: A styling language that makes HTML styling rules more flexible and repeatable.
- PHP: The backbone of WordPress; what most of the WordPress software package, as well as WordPress themes and plugins, are written in.
- MySQL: The system that structures all WordPress databases. The way to talk to a MySQL database is through MySQL queries, although WordPress developers can usually use premade PHP functions bundled with WordPress itself in lieu of writing queries directly.
Okay, now for the big diagram:
Simple, right? Don’t worry, we’ll spend the rest of this post explaining how the diagram works.
The steps involved in loading a WordPress page
The diagram shows the flow required to generate any page in WordPress. That flow works as follows:
1. HTTP request
Your browser asks the server to give back the webpage you’ve requested.
When you enter a URL, this tells the client—your browser—what site you want to view, and what page or post on that site. Through a convoluted process, your browser sends a request, called an HTTP request, to the server where the site is stored. (HTTP is just the language computers use to transfer webpages to each other; you don’t need to know the details here.) This request is basically your client asking the server to give back the webpage you’ve requested.
2. Initial WordPress PHP processing
When the server receives your client’s HTTP request, it does some initial PHP processing to engage its internal environment.
WordPress’s voluminous PHP code is mostly written to turn HTTP requests into different types of webpages. For example, your WordPress theme is a bunch of PHP templates that form the skeleton of your site’s various layouts, which vary depending on the nature of the post or page being requested.
When the server receives your client’s HTTP request, it does some initial PHP processing to engage its own internal environment and interpret the client’s HTTP request to understand what the client is asking for.
3. Database querying
WordPress uses MySQL queries to retrieve post contents and other needed information from the database.
However, to know which template to use for a given webpage—and to actually get your posts themselves!—WordPress must tell the server to make a trip to the WordPress database, where posts, post metadata, and permalink information are stored.
This database usually lives on the same server as the WordPress site itself, but it’s not directly accessible except through MySQL. (If you use an FTP client, you won’t find it in a “database” folder next to “themes” and “plugins,” for example.)
Using MySQL queries, WordPress’s PHP scripts get the database information they need to generate the webpage you requested—including the post contents (text and HTML markup) that will be the main content of the webpage you’ve requested.
4. More WordPress PHP processing to generate an HTML page
This step in the process consists of using PHP to process the retrieved post data into pure HTML markup.
After its trip to the database, WordPress knows what PHP template to use, and has actual post content that it can write to the page. This is where the PHP code written your theme and most plugins come into play.
This step in the process consists of using your theme templates, plugins, and the rest of the WordPress PHP codebase to process the retrieved post data into pure HTML markup.
Why is this necessary? Because your browser can’t understand PHP—only a server can. Put differently, PHP outputs HTML to send back to a browser, because HTML is what a browser can understand.
5. HTTP response
The server sends a clean HTML document back to your browser using HTTP.
This whole time, you and your browser have just been sitting there while the server ground away on itself. Now, finally—having made its journey to the database and fed the resulting posts through the PHP files that make up the site’s theme and various plugins—the server is ready to send a clean HTML document back to your browser. It sends the HTML back to your browser. It does this using a response written in HTTP, the same language as the initial request.
6. Browser rendering
Now that the client (your browser) has gotten the HTML-containing HTTP response it requested, it can start to build the result into a webpage.
Once the browser has received the HTML and all the associated resources it requested, we’re finally done with the server. If the server blew up now, you and your browser would still have the webpage and everything on it—at least until you closed the window.
Now the browser can do its main job: rendering HTML and related resources into something that looks like a webpage.
Now the browser can do its main job: rendering HTML and related resources (images, etc.) into something that looks to humans like a webpage. Every webpage, as interpreted by your browser, is a combination of plain text and associated resources, visually organized according to various rules given to the browser by HTML and CSS.
When your browser has finished rendering all the resources that were sent to it, you can finally see the WordPress page that you requested when you typed an address into the URL bar.
7. Interactivity through client-side scripts
Your browser can generate interactive effects through client-side scripting.
But sometimes there’s more! On some sites, when you hover over an object, it changes color. And some pages actually know what you’re doing as you interact with a page—for example, when you enter your password twice to sign up for something, the page will give you an error message the moment the two passwords don’t match.
None of this involves the server—it could still be a smoking crater as far as we know. Rather, these effects are handled through client-side scripting: pieces of code that were sent to your client (your browser) by the server as part of its HTTP response, but which run in the client itself.
So what is server-side and what is client-side?
In term of the flow above, steps 2 though 5 are server-side, and 1, 6, and 7 are client-side. Let’s look at those terms and you should understand why this is the case.
PHP and MySQL are always server-side.
For WordPress sites, server-side means: “Happening during the internal machinations a server goes through as it tries to serve a page back to a client who’s requested it.”
PHP can’t track your mouse: by the time your browser is tracking mouse activity, the server is no longer involved.
As a rule of thumb, PHP and MySQL are always server-side—they only run in a server environment. A web browser doesn’t understand them.
This is why PHP can’t track your mouse. By the time your browser is tracking mouse activity, the server is no longer involved.
Client-side scripts are stuck with what the server has given them.
So client-side scripts are stuck with what the server has given them: by the time client-side scripts are able to run, the server has already finished its transfer.
This is why, for example, you can’t navigate to another page on the site without experiencing a “reload” flicker: getting the contents of a new page requires a new HTTP request, a trip back to the server and the WordPress database, and an entirely new HTTP response (followed by numerous other HTTP requests and responses for resources like CSS stylesheets and images). Your browser must then build this new set of HTTP responses into a page.
Well, that’s a lot about server-side and client-side—but not a word (or fancy PowerPoint graphic) was wasted if you’re starting to grasp this crucial distinction. WordPress will make 1,000 times more sense relative to not understanding it.
We’d love to talk about any questions or thoughts you may have—say hi in the comments below!
Image credit: Ian D. Keating