StackPath offers two integration options to WordPress web administrators, Static Assets Integration or a Full Site Integration. The integration method that is best for you will vary with your individual needs. The following article will outline how each option works to help you make the best selection possible.
Full Site Integration (recommended method)
A Full Site integration delivers all content for your site through the StackPath CDN and is required to utilize the StackPath WAF. During the integration process, DNS changes are required.
| Dynamic | Static | ||||
|
HTML rendered from... |
Common files | Images | Fonts | Video | Audio |
|
PHP |
.js .css .webp |
.jpg .jpeg .gif .ico .png .bmp |
.ttf .eot .woff .woff2 .otf .svg .svgz |
.mp4 .m4a .m4v .mov |
.wav .mp3 .wma .ogg |
How it works
A Full Site Integration is the most robust CDN offering StackPath provides. This method gets the most out of StackPath's optimized network; you can pass an entire website through our services. To route every request through StackPath you must change where users look for your website, not only where your server says to find assets. A DNS change must be made.
Creating a DNS record, discussed below, will route all requests through StackPath's PoPs. This method can cache both static and dynamic assets and deliver them from the CDN.
To implement this integration, the URL of your website must resolve to StackPath's Anycast IP address. You can do this by creating a DNS record, either with StackPath DNS or your provider, in one of two ways:
- A CNAME pointing from your subdomain (www) to your Edge Address
- An A record pointing from your apex domain to the Edge Address's IP Address
This step should be completed with an ANAME record or through Domain Shortening if offered by your DNS provider, as StackPath's anycast IP is subject to change at any time.
Upload an SSL certificate that covers your domain and any subdomains when using HTTPS. If not done before DNS changes, your site will display an untrusted certificate. After your Full Site integration, you will have access to WAF without modifying any configuration. Simply turn WAF on in your Control Panel.
Before CDN Integration:
As you can see, all files are delivered from a single domain. In this case, "www.example77.com" is pointed directly at the site's Origin web server. For every instance the webpage is loaded, dozens of requests must be served. When traffic picks up, the site will have progressively longer response times and is likely to return errors to some users.
After CDN Integration:
Once the DNS changes are propagated, "www.example77.com" is delivered through the StackPath network. (Full propagation usually takes about 24 hours) Instead of all of these assets coming from your origin server, they are coming from one of our Edge locations, as seen by the difference in IP addresses.
The CDN will now deliver all assets that were initially delivered through your Origin. Unlike a Static Assets integration, you cannot control the files that are cached on the CDN via a Wordpress plugin. Management of file caching must be done through the StackPath control panel. Optimization plug-ins and server-side caching plugins can still be used on Wordpress.
Why use WAF?
Most Wordpress HTML is generated server side by PHP. These HTML pages if cached improperly can lead to preventing users from logging in, submitting posts, or even logging into the admin panel. For this reason, we always recommend using WAF with a Wordpress Full Site integration. WAF enables precise customization of caching for particular files so that any unwanted file caching can be redirected straight to your Origin.
Before WAF is enabled
There are a couple settings that should be enabled for WAF and CDN work correctly with your WordPress site.
- WAF > Policies > Set CMS Protection > Whitelist WordPress admin logged-in users to On
Your requests could get blocked due to the content of the requests (e.g. scripts). This will whitelist the session of a logged in admin user, allowing all administrator to navigate normally. - WAF > Policies > Set CMS Protection > Whitelist Origin's IP to On
Enable this policy to whitelist requests coming from the origin for plugin updates and general CMS updates
After WAF is enabled
A simple way to check if WAF is working is to blacklist your IP in the StackPath control panel under Sites > Firewall. Try to then access your site; you should be blocked.
Alternatively, you can examine your network requests. Once WAF is enabled, you'll see a new request on every webpage. The request will appear to originate from your Origin and include the directory /sbbi/. This is your WAF validation request, and its presence means every request is passed through StackPath WAF.
If you think Full Site with CDN and WAF is the right combination for you, take a look at the StackPath CDN with WAF Setup Guide to get you started.
Static Assets Integration
How it works
With a Static Assets Integration, StackPath caches file types of your choosing and serves them when your users request. A WordPress plug-in is used to replace references to your Origin with the Edge Address or a custom Delivery Domain. When an index page loads from your Origin, any asset replaced with your chosen URL is pulled from the closest StackPath location.
By default, you will be provided with a Edge Address to integrate into all Index page asset references. This URL can serve both HTTP and HTTPS without additional action. If a Delivery Domain (a subdomain that contains your domain name) is added, you will have to upload an SSL certificate to serve HTTPS.
With this integration, the CDN can be enabled or disabled with no burden of DNS delay. We recommend this method if you want a minimally invasive way to speed up your site and don't yet need the extra security provided by StackPath WAF.
This type of integration typically utilizes a CMS plugin (like w3tc for WordPress) to delivery Static Assets (images, CSS, or javascript) from the StackPath edge servers instead of the Origin Server and does not require changing your DNS. For example, if we wanted to perform a Static Assets integration for a WordPress site, www.example77.com, here is what a link to a CSS asset might look like before the integration.
<link rel="stylesheet" id="dashicons-css" href="https://example77.com/wp-includes/css/dashicons.min.css" />After installing a plugin, the URL has been rewritten as follows:
<link rel="stylesheet" id="dashicons-css" href="https://a2c3d3e9.stackpathcdn.com/wp-includes/css/dashicons.min.css" />Tip: If you would rather use a custom delivery domain, like cdn.rackhero.com, please use the Delivery Domains feature under Sites --> Settings.
Supported Assets
A Static Assets integration can serve the following files by default.
| Common files | Images | Fonts | Video | Audio |
| .zip .js .css .webp .txt .m3u8 |
.jpg .jpeg .gif .ico .png .bmp |
.ttf .eot .woff .woff2 .otf .svg .svgz |
.mp4 .m4a .m4v .mov .ts |
.wav .mp3 .wma .ogg |
These assets are static because their contents are the same regardless of the user. The file may appear in multiple locations - Google may pull an image onto search results, and you may use it on, your website - but both will be the same file shown to users.
An Assets integration uses a WordPress plugin to rewrite selected reference URLs on your index pages to StackPath's PoPs. This method caches only static assets and delivers them from the CDN. Dynamic assets are not cached.
Your assets from StackPath must be delivered from an alternate URL than your main website. The alternate URL can either be a StackPath provided Edge Address or a Delivery Domain. If you prefer to have assets delivered via a subdomain, add a Delivery Domain and upload a corresponding SSL certificate if HTTPS is required. That subdomain is now your static assets Edge Address, ready to undergo integration.
Before Integration:
As you can see, all files are delivered from a single domain. In this case, "www.example77.com" is pointed directly at the site's Origin web server. For every instance the webpage is loaded, dozens of requests must be served. When traffic experiences high load, the site will have progressively longer response times and is likely to return errors to some users.
After Integration:
Now that the Wordpress plugin has rewritten asset URLs our web server will handle far less traffic. In this example, two different delivery methods from the CDN have been set up as a demonstration. We recommend choosing Delivery Domains or the Edge Address.
- Delivery domain: cdn.example77.com - A CNAME record pointing "cdn" subdomain to the Edge Address K7i7r8n7.stackpathcdn.com. A Custom SSL certificate was uploaded to serve under this subdomain with HTTPS.
- Edge Address: k7i7r8n7.stackpathcdn.com - A unique URL provided by StackPath that comes with each Site you create. No need to upload SSL certificates and no need to make any DNS changes.
The index page is still delivered from your Origin with a Static Assets integration. For every 1 web page load, your server will receive a minimum of 1 GET request. It's only after that initial request to your Origin that the end user's browser can parse the Asset URLs and request them from the StackPath CDN.
Recommended plugins
The biggest hurdle to getting your website going with an assets integration is choosing the right plug-in for your needs. Here's a small subset of plugins that you can look through and determine which fits your needs best.
| Plug-in | Features |
|---|---|
|
|
|
|
| WP Fastest Cache |
|
| CDN Enabler |
|
| CDN Rewrite |
|
After choosing the right plug-in, take a look at our CDN setup guides to walk you through the specific steps to take for plug-in set up.
What next?
Now that you have picked the right integration method for you, it's time to begin the Wordpress set up. Here are a few articles to point you in the right direction.