Skip to content

How Does it Work?

QUIC.cloud CDN is a reverse-proxy content delivery network, designed to improve the performance of WordPress websites. It does this by caching a site’s content physically closer to end users in all regions of the world. Closer content means faster response times and a better page experience for the user. The CDN acts as a mediator between the end user requesting a page from a WordPress site and the origin server hosting the site. 

QUIC.cloud can cache both static and dynamic WordPress content, and is exclusively compatible with the LiteSpeed Cache plugin for WordPress (LSCWP). The CDN requires LSCWP, and a domain cannot be added to QUIC.cloud CDN without it.

To understand how QUIC.cloud works, consider the following basic illustration of how users access your WordPress site before setting up QUIC.cloud CDN on your domain:

When a visitor using Laptop-01 requests a page on your WordPress site, the request goes directly to your origin server. Let's call that Origin-Server-01. Origin-Server-01 then generates the dynamic WordPress PHP page and sends it back to be displayed in the browser of Laptop-01.

This process consumes memory and computer resources each time a page is generated. If there is a server-level caching mechanism like LSCWP, the page may be served from the server cache, which provides a considerable performance boost. But it still takes time to send the page back to the user. Users who are geographically far away from Origin-Server-01 may experience relatively long wait times for the page to be delivered and displayed on their device.

Below is a basic diagram that illustrates how users access your WordPress site after enabling QUIC.cloud CDN:

  1. A visitor using Laptop-01 sends a request for a page from your site, which is hosted at Origin-Server-01.
  2. QUIC.cloud uses the DNS request information to select the best node available to handle the request.
  3. In this case, nearby node CDN-NODE-01 is instructed to handle the request.
  4. CDN-NODE-01 receives the request and checks its cache storage. If the page is not found, it sends a request for the page to Origin-Server-01.
  5. Origin-Server-01 generates the requested page and sends it back to CDN-NODE-01.
  6. CDN-NODE-01 checks the cache control headers on the returned page and if permitted, a copy of that page is saved to its cache storage.
  7. CDN-NODE-01 sends the requested page to Laptop-01 and the page is displayed in the web browser window. (If you were to check the response headers for the page, you would see that the x-qc-pop header indicates CDN-NODE-01 served the request, and the x-qc-cache header has a value of miss.)
  8. The next time a request for the same page is directed to CDN-NODE-01, the node will send back the cached page to the user and will not need to contact Origin-Server-01 at all. This saves time for the user and it saves processing resources at Origin-Server-01.
  9. Pages are stored at CDN-NODE-01 for 24 hours from the last access. So, pages that don’t see much traffic will be removed from the node's cache after about a day, but pages that are accessed at least once daily will remain in CDN cache for up to 7 days.