What is a CDN and how to use it on a WordPress website?

Hosting Mautic QuickStart -50% with support in Spanish
24 hours and free training

Send up to 1,000,000 emails/year. Mautic support in Spanish 24 hours, 365 days

You’ve probably heard a lot about CDNs for WordPress and their ability to speed up web pages, among other uses.

And it doesn’t surprise me, since the browsing speed on a website It is, without a doubt, one of the most relevant factors to improve the user experience, while your users navigate through the pages of your website.

Today, a page that takes several seconds to display on the screen will cause the user to lose patience and abandon it, to find what they are looking for elsewhere.

After all, everything on the Internet is just a few mouse clicks away, so why wait when you can get to another site with little effort?

In turn, the user experience influences the SEO of a websitesince Google penalizes pages that take too long to load, precisely because of their negative effect on this factor.

This, until now, was reason enough to get our act together and start optimizing images, using plugins that consume few resources, etc.

Until we discovered that CDN’s exist!

Unlike other optimizations carried out on resources or components installed on the web server or WordPress, with a CDN external servers are involved, which interact with the web server to speed up the download of a web page and, consequently, the speed of browsing.

Next, I will show you what it is, how it works and, from a practical point of view, how you can install and configure a CDN in your WordPress, to take advantage of all its advantages.

What is a CDN?

A CDN is, very briefly, a set of servers distributed throughout the planet and connected to each other through the Internet.

But, for me, the best way to understand what a CDN is and how it works is to first understand the process that follows, from when a user enters an address in their browser until the corresponding web page appears on the screen.

Although there are no significant differences with other content managers, in order to simplify the description of this process, we will assume from now on that we access the web page of a WordPress site. The procedure would be the following:

The user enters the address in his browser.
The browser identifies the server corresponding to that address and requests the corresponding web page.
The server receives this request and WordPress generates an HTML file, based on the information stored in its databases.
This server sends this HTML file to the browser that made the request (point 2).
When the browser receives the HTML file, it reads and interprets its content.
During this interpretation, references (web addresses) to various resources may appear, such as style files or images, which are part of the content or structure of the web page.
For each of these references, the browser requests that resource from the same server.
The server attends to each of these requests, locating the corresponding resource on your hard drive and sending it to the browser.
As the browser receives these resources, it generates and displays the web page to the user.

As a general rule, all the resources of a page (point 6) are hosted on the same server that generated the HTML file (point 3).

The use of this type of tool frees the hosting server from this last task, so that it will only have to be in charge of attending to the browser’s requests (points 3 and 4). For its part, the CDN will be responsible for dealing with references to resources (points 7 and 8).

How does a CDN work?

If we analyze in detail the process described in the previous point, we will observe that a large part of the work carried out by the hosting server is, paradoxically, not dedicated to the most important task: generating and delivering the HTML page to the requesting browser.

Instead, the hosting server spends a lot of processing time simply locating and delivering resource files to the browser.

Among these resources, the most frequent are images, which usually take up much more space and, consequently, consume more bandwidth than the HTML page itself, no matter how optimized they are.

With this resource, the hosting server can focus its work on what is important: respond to user requests, generate the HTML files that they request, and deliver them back.

Until now, we have only stopped to see the external effect of using it, but surely you are beginning to glimpse some of the advantages that it can bring us.

But, before seeing in detail what it is for, let’s stop a little to know how CDN’s work and thus better understand all its possibilities.

Schematically, the operating principle of a CDN is based on the following 3 points:

Having an extensive network of servers, connected through the Internet, scattered throughout the entire terrestrial geography.
Storing locally on those servers a copy of all the static resource files that we have on our hosting server.
Interfering and attending to the requests of these resource files when a browser requests them to generate and display the web page to the user.

Let’s look at each point in more detail below…

► Having a network of servers

Although until now we have referred to the CDN in a singular way, as if it were a single element, in reality it is a set of servers, distributed throughout the planet and connected to each other through the Internet.

Thanks to this provision, when a browser requests a resource, the server that is closest to its own serves it, greatly reducing the time it takes to send and receive the data.

The internal management and operation of this network of servers is completely transparent both for the owner of the website that uses the CDN, and for the users that browse through its pages.

To both, it has the outward appearance of a single server delivering the resource files over the Internet.

► Storing resources locally

It makes sense, since if the CDN (we don’t care which of its servers) is going to deliver, say, an image to a browser, it must have that image file on its own hard drive.

If you had to request it from the hosting server, we would lose all the benefits it could provide us. It would even negatively affect performance, since two requests would have to be made for the same file.

The way in which these files arrive, are stored and distributed among its servers, which may vary depending on the configuration of the service and is also transparent to us, without us having to intervene at all.

By default, most CDN’s make a local copy of all resource files when they are first installed and activated. Likewise, the CDN itself is in charge of checking that its local copy is updated with any change in the original file of the hosting server.

► Interfering and responding to resource requests

So far, we have a network of servers and, distributed on them, a copy of all our resource files.

However, references (web addresses) to these resources from the HTML code of web pages remain to our hosting server.

This means that when the browser reads and interprets these web addresses in the HTML code, it will still request them from the hosting server, not the servers.

Therefore, in order for the browser to download those files from the CDN, those web addresses will have to be changed to point to the CDN servers instead of the hosting server.

Here we can get a little scared: do we have to change the web addresses of ALL our images?

In principle, yes, but the providers of this type of tool provide tools (such as a WordPress CDN plugin) to do it for us automatically, so we don’t have to worry about that either.

► Modes of operation of a CDN

WordPress providers can choose between two alternatives when it comes to interfering and meeting resource requests:

We have already described the first one above: a WordPress CDN plugin, provided by its provider, which modifies the web addresses in the HTML code of the web pages, so that they point to the respective copies of the resource files on the servers.

Once this plugin is installed and configured, the process of changing web addresses is automatic and transparent, both for the owner of the website and for the users who browse it, who do not have to know where the resources are actually hosted.

On the other hand, in the second modality, the web addresses on the pages do not vary, but rather the servers serve those addresses directly, as if they were the original hosting server. In this case, the WordPress CDN server works as a proxy, sitting between the browser and the hosting server.

When the server can supply the requested resource, because it has a local copy, it supplies it right away. If it cannot supply it, either because it is not stored on its hard drive or because it is an outdated copy, it redirects the request to the hosting server for service.

With this modality, the hosting server will always be behind the CDN server, so you get an additional layer of security against possible external attacks, which must first go through it.

In addition, it has the possibility of storing a static copy of web pages, behaving as a cache server, especially useful when our content pages change infrequently.

The CDN server itself is responsible for periodically updating these static copies to ensure that users always have access to the most recent version of the pages.

What is a CDN for?

Now that we know what this term consists of and how it works, let’s see what services a CDN provides us in WordPress and how we can take advantage of them to improve the response time of our server and, consequently, that of our users:

1. Storage and delivery of static resource files

Basically images and CSS files. This is the main feature of servers and almost their reason for being.

As mentioned above, by having a local copy of the static resources, the hosting server is freed from having to send them to the browser when a user accesses one of its web pages, freeing it to dedicate itself to other tasks.

2. Dynamic Resource Cache

Dynamic resources are those generated by a content manager each time the website is visited.

For example, in WordPress, web pages are generated every time a user accesses…