Speed up WordPress with W3 Total Cache and Amazon CloudFront (CDN)

How to greatly improve your WordPress website’s speed using W3 Total Cache and Amazon CloudFront

Does your website seem to take forever to load? Are your visitors not making it past your homepage out of frustration? Are you producing useful content and optimizing your site for search engines, and wondering why your site still ranks so low? The speed of your website can be nearly as important as your content, design, and features, and can be the difference between users staying on your site, or going to your competitors.

Having a fast-loading website can greatly improve your user’s experience, keep your visitors on your site much longer, and improve your search rankings (Google uses page speed as a page ranking criteria).

One of the easiest and most efficient ways to improve the speed of your WordPress site is by caching. In about only 15 minutes, you can greatly reduce the time it takes for your WordPress site to load by using the free W3 Total Cache plugin. My own website went from having a page load time of 69 (based on Google Page Speed) prior to installing Total Cache, to 97 after installing the plugin and using the settings detailed below.

A great thing about W3 Total Cache is that includes functionality that previously required the use of multiple plugins to achieve. In addition to caching every aspect of your website, Total Cache includes easy integration with CDNs, features built-in minification, advanced caching options and more.

This article takes you step-by-step though setting up and optimizing W3 Total Cache for your site, as well as a section detailing how to set up and integrate Total Cache with Amazon’s CloudFront CDN. While these settings had a great result for my site, the needs of your specific site might vary. That said, using W3 Total Cache even with the default settings should give your site a significant performance boost. You can tinker endlessly with different caching options and expiration settings, but the goal of this article is to help you understand each option, and let you set up the plugin so you can forget about it and focus on your design and content.

Let’s get started!

Installing W3 Total Cache

Like most WordPress plugins, W3 Total Cache can be easily installed through the Plugins section of your WordPress admin screen, although it does require a few of additional quick steps:

1. Deactivate (and delete, if possible) any other caching plugin you are using.

2. Temporarily set your wp-content and wp-content/uploads/ folders to chmod 777. Using your favorite FTP client (such as Cyberduck or FileZilla), right click on the ‘wp-content’ folder. If using Cyberduck, select ‘Info’. Click on the Permissions tab, and change the permissions to ‘777’ and press Enter. Using FileZilla, right click and select ‘File Permissions’. -Repeat this for the wp-content/uploads/ folder.

3. Install and activate the Total Cache plugin through the Plugins section your WordPress admin screen.

4. Go back to your FTP client and change wp-content and wp-content/uploads back to chmod 755.

Once W3 Total Cache is installed, you will see a new section on your WP admin screen titled ‘Performance’. The Total Cache options panel is divided up into several sections, including General, Page Cache, Minify, Database Cache and several others.

General Settings

Let’s first go over each section on the General page of Total Cache. Think of the General tab/page as the dashboard where you can turn each type of caching and function on and off. Detailed settings for each individual option will be covered later in this article.

Page Cache

Pages on your website consist mainly of content, images, and styling (CSS). Web servers typically have to dig through several folders and files, pull information from several sources, and then output the information as a complete webpage. This takes time, especially when the server tries to handle several requests at the same time, which can slow down your site and increase page load time. Instead of piecing together the page on the fly, page caching takes the entire output and stores it as a static html file. This lets the server retrieve the information much faster, helping your pages load almost instantly.

Recommended Settings:

Page Cache - Speed Up WordPress with W3 Total Cache and CDN


Minify is a great feature that can speed up your website by shrinking the size of your CSS, Javascript, and HTML files. Minify will remove things like unneeded spacing and comments from your code.

Minify includes both ‘Auto’ and ‘Manual’ options. If you select ‘Auto’, the detailed settings on the ‘Minify’ tab of Total Cache will basically be ignored.

Important: If you want to use a CDN for your minify files, you must select ‘Manual’. If you use a CDN and select ‘Auto’, the minified files will be served directly from your (ie, your hosting company’s) servers, and not the CDN. I personally prefer this method, as it can make updating your site easier. CDN’s are discussed in more detail further on in this post.

Recommended Settings:

Minify Settings - Caching Settings

Database Cache

Being that WordPress sites run on a database, database caching can greatly improve you’re site’s load time. W3 Total Cache can cache all database queries within a specified time frame.

Recommended Settings:

WordPress Database Caching

Object Cache

Object Caching is the caching of thing like images, videos and documents on a web page. Object Caching stores a copy of each object so each object can be served directly from the cache. Objects, such as images, are typically not modified often once you post them, so caching objects for long periods of time can help improve you site’s load time. The increase of speed you might see from object caching can vary based on the drives your host is running.

Recommended Settings:

Object Cache WordPress

Browser Cache

Browser caching reduces the amount of requests your server makes every time someone visits your site. Each time someone visits your site, their web browser stores a copy of your site. On the next time they visit your site, their browser will check whether any changes have been made since their last visit. If changes have been made, it will load the new version. If no changes have been made, it will load the copied version. This can greatly improve the speed of your site since your server does not have to handle so many requests at the same time.

Recommended Settings (this is one of the main reasons you installed this plugin, so in case it’s not obvious, enable this):

WordPress Browser Cache Settings

CDN – Content Delivery Network

One of the great things about W3 Total Cache is that it includes support for several popular CDNs including Amazon CloudFront, MaxCDN, Rackspace Cloud Files and others. While these are paid services, they are typically quite affordable, with services like Amazon CloudFront averaging only a few dollars a month. A CDN (Content Delivery Network) is a network of servers that delivers a web page to users based on their geographic location. The closer a website visitor is to the server, the faster the content will be delivered to them. Your hosting company might be based in the U.S., but by using a CDN, a visitor to your site living in Germany can have your site automatically delivered by a server in Germany, for example. So, even if you don’t see a significant improvement in your site’s speed after enabling a CDN, many of your website visitors will notice a big improvement.

CDNs function as either ‘origin push’ or ‘origin pull’. With origin push, the CDN acts like a second host. You upload all your files to the CDN (this can be automated through W3 Total Cache), and the CDN caches and serves the content from their servers. The benefit to using origin push is that you can specify what content is uploaded, when it is uploaded, and when it expires. The downside, is that every time you make changes to things like your CSS and theme files, you have to manually re-upload them to the CDN. With some CDNs, such as Amazon CloudFront, uploading an updated file unfortunately won’t just overwrite the previous file. You have to send an invalidation request, or rename your files. If you are like me, and are constantly tinkering with the design and layout of your site, using origin push can be a bit challenging. In other words, origin push gives you more control, but also more work.

With origin pull, rather than having to upload all your files to the CDN, the CDN looks at your current servers, pulls the information for you, and then serves it to your visitors. You simply leave your content on your
server, and rewrite your URLs to point to the CDN (again, W3 Total Cache makes this a quick and painless process). The CDN will then cache the files, and serve those files until they expire. Using origin pull can make your site slower for users the first time they visit your site, but it will be fast once it caches your files. Besides being very easy to set up, the other great thing about origin pull is that changes you make to your site are updated on the CDN very quickly. I personally prefer origin pull to origin push, as it requires less work and is easier to use.

If you chose to use a CDN, you have to set up an account with a CDN and configure your account on the CDN tab before enabling this. CDN options are discussed it even greater length further on in this post.

Recommended Settings:

WordPress CDN

Varnish & CloudFlare

Varnish Cache and CloudFlare are two 3rd party web application accelerators that can be used in place of many of the features included with W3 Total Cache (CloudFlare also offers additional services such as security protection and analytics as well). As I do not have experience using either of these services, they will not be discussed at length in this post, but feel free to leave a comment if you’ve used either of them.

Detailed Settings

Page Cache – Detailed Settings

Once you’ve enabled Page Cache on the General page, clicking on the Page Cache link at the top of your screen will bring you to the detailed settings page.

Make sure ‘Cache Home Page’ and ‘Cache Feeds’ are both selected. Being that your homepage is typically the most visited page on your site, it should go without saying that it is important for it to be cached. ‘Cache SSL requests’ is only recommended if you are using SSL, which generally requires a license certificate. If you are not sure whether your site uses SSL, if your browser displays ‘https://’ in your URL, your site uses SSL; If it displays ‘http://’, it does not. The ‘Cache URI’s with query string variables’ option caches things like search results. To the best of my knowledge, this is not supported in Disk-Enhanced mode, so we are going to leave this unchecked.

‘Don’t cache pages for logged in users’ is an interesting option. One downside to WordPress is it can be tough to use for ‘staging’, meaning there is not a great way for you (as an admin) to view changes to your site before making the changes live. Enabling this feature can accomplish this for many sites. This feature essentially disables the page cache for you, while keeping it on for your visitors. So you can view changes to your site, while your visitors will be served a cached version of your site until the cache is cleared. The catch to this is that it applies to all ‘logged in’ users; not just admins. So if your site allows visitors to create accounts and log in, this won’t be ideal.

Lastly, caching 404 pages is only needed for certain sites (typically older sites) that have a lot of broken links. Assuming your site is up to date, this option does not need to be enabled.

The General Page Cache settings should look like this:

WordPress General Cache Settings

For the ‘Advanced’ Page Cache settings, you should be fine with leaving it with the default settings. Set the Garbage Collection Interval to 3600 seconds, and leave ‘Never Cache The Following Pages’ set to wp-.*\.php and index\.php. If you
have a page on your site that is constantly changing, you can add it to the ‘never cache’ list.

WordPress Advanced Cache Settings

In the Cache Preload section, you can select ‘Automatically prime the page cache’, set the update interval to 900 seconds, set Pages per interval to 10, enter enter the URL of your sitemap. The Google XML Sitemaps plugin can automate the sitemap creation and updates for you.

WordPress Cache Preload - Speed up WordPress

Lastly, for the ‘Purge Policy’ section, you should be fine with the default settings.

Minify – Detailed Settings

This page gives you the ability to set up the URL rewrites, and enable minification of HTML, CSS, and Javascript. *One important thing to note is that if your site runs JQuery, you should disable the JS minification.

Minify WordPress Settings

WordPress HTML XML Caching Settings

Minify Java Script

Minify CSS

WordPress advanced Minify Settings

Database Cache & Object Cache – Detailed Settings

In most cases, the detailed Database Cache and Object Cache settings can be left as the default settings.

For Database Cache, keep ‘Don’t cache queries for logged in users’ selected. For both the Database and Object caches, the ‘Maximum lifetime of cache objects’ can stay at 180 seconds, and the ‘Garbage collection interval’ can stay at 3600 seconds. If you have any pages that rely heavily on database queries, you can add them to the ‘Never cache the following pages’ field.

Browser Cache – Detailed Settings

For the Browser Cache, I have nearly all of the settings checked except for caching after a settings change and 404 errors:

Below are the settings I use for CSS and JS:

Below are recommended settings for HTML & XML:

And here are the settings for Media & Other Files:

CDN (Content Delivery Network) – Detailed Settings

If you are using a CDN, you’ll have to decide what you’ll want to use the CDN for. You can have your CDN serve all your files, or you can decide to just use it for things like images and theme files. As noted earlier, my personal preference is to mainly use the CDN for serving images, and not CSS and JS.

If you have ‘Auto’ selected on the Minify details page, the option to select ‘Host minified CSS and JS files’ will be greyed out on this page.

Important: Be careful with the option to ‘Import external media library attachments’. If, when writing a post in WordPress, you upload an image to the Media Library, and then add the image by using an img tag, for example, that is
considered an ‘image attachment’. If you copy images from other sites into posts, those are also considered attachments. This option will upload those images hosted by other sites onto your server, and then to Amazon. If you use in-post galleries, image attachments are generally kept separate from the gallery. I learned the hard way that checking this option in total cache will result in all your attached images being automatically added to the gallery.

Setting up a CDN using Amazon CloudFront

Lastly, I will walk you through the steps of setting up Amazon CloudFront as a CDN using W3 Total Cache. When setting up CloudFront for the first time on my site, I ran into several issues. I read through several tutorials covering the CloudFront setup process, and found most of them confusing. Amazon offers very detailed information about Cloudfront and their other services, but while Amazon is great at developing products, let’s just say that writing easy-to-understand documentation is not their strong suit. I will try to describe Amazon CloudFront simply, and to the best of my understanding.

Using Amazon CloudFront requires that you first set up an account with Amazon Web Services (AWS). The remainder of this post assumes that you have already done that.

There are two aspects of Amazon Web Services that we are concerned with here: CloudFront and S3 (Simple Storage Service). CloudFront is the Content Delivery Network, and S3 is online storage. S3 is used in conjunction with your current web host. Both S3 and CloudFront are paid services, but are very affordable, and you only pay for what you use (CloudFront should cost you somewhere in the area of $1-$3 a month for small site).

CDNs function either as origin push or origin pull.

Origin Push: You upload your files (including theme files, images, CSS files, and Javascript libraries) onto S3. Your files are stored in what are referred to as ‘Buckets’. Buckets are simply containers that will hold your folders and files. CloudFront then copies the files from your buckets to local servers around the world. CloudFront will then grab your files from the S3 servers, and then serve them on your website.

Origin Pull: Origin pull bypasses the need for S3 (although my understanding is that you still must create a bucket on S3, even though CloudFront doesn’t use it). Instead of grabbing info from their S3 servers, the CDN will pull the info from your (or your hosting provider’s) servers. When someone in England, for example, visits your site for the first time, CloudFront will store your site on a server in England. Subsequent request from England will then be served by that server.

As I stated earlier, origin pull is an easier method to use, since pushing out updates to files once they are stored on S3 presents some challenges that require some additional steps.

Let’s get started with setting up Amazon CloudFront.

1. Enable CDN. Enable the CDN on the W3 Total Cache General page. Select Amazon CloudFront from the pull-down menu (either pull or push).

2. Configure S3. Log on to Amazon Web Services, and click on the ‘S3’ tab. Click ‘Create Bucket’ on the left side of your screen. Enter a Bucket Name (this can just be the name of your website, for example). Click ‘Create’.

3. Enter Credentials. We now have to get a couple pieces of information from your Amazon Web Services account to link it with Total Cache. In AWS, click on your name in the top right corner, and then select ‘security
credentials’. Scroll down to the table pictured below.

Amazon CloudFront Credentials Settings

Copy & Paste the Access Key ID and Secret Key into the corresponding fields on the Total Cache CDN page.

Total Cache CDN Configuration

4. Create a Distribution. Enter a name for your distribution in the origin field (this can be something like yoursite.com) and then click ‘Create Distribution’. Replace Site’s Hostname should then
automatically be filled in with random characters. Click the ‘Test CloudFront distribution’ button to make sure it works. Click the ‘Save all Settings’ button.

5. Check the Distribution. Go back to the CloudFront tab in AWS. You should see the newly created distribution. It will take a little while to download, depending on how much content you have on your site.

6. Set up a CNAME. Without setting up a CNAME, your images will have an Amazon web address. With a few steps, you can change it to your own name (such as images.yoursite.com, or media.yoursite.com).

Open up your hosting Control Panel (this may vary depending on your host). Scroll down to ‘Domains’ and click ‘Simple DNS Zone Editor’. Fill in the CNAME record fields. For the Name, use something like images.yoursite.com. For the CNAME field,
you’ll need to go back to the CloudFront tab in Amazon Web Services. Where is says Domain Name, you will see something like h2j4uj5k8xnm6.cloudfront.net. Copy & Paste than into the CNAME field on your hosting control panel.

Amazon CloudFront CNAME Settings

7. Add CNAME to AWS. Go back to the CloudFront tab in AWS. Right Click on the CNAMEs field next to your distribution and click ‘Edit. Enter your CNAME in the corresponding field and click ‘Yes, Edit’.

8. Add CNAME to Total Cache. Go back to the Total Cache CDN page. Press the ‘Add CNAME’ button, and enter your CNAME (you can leave the ‘Replace site’s hostname with’ field alone). Press Save All Settings’.

If you are using origin pull, you can check to make sure CloudFront is working properly. Open up your website, right click on an image, and select ‘open in new tab’. The URL of the image should now start with your CNAME.

9. Additional Steps for Origin Push. If you are using origin push, there will be buttons on the top of the Total Cache CDN page. Use them to automatically upload the different types of files you want stored on S3. Once your files are uploaded, Go to the S3 panel in AWS and select your bucket. Right click on each folder in the bucket, and select Make Public. If you do not set your folders as public, CloutFront will not be able to retrieve them from S3.

You’re all done!

While it might seem like a lot of steps, setting up W3 Total Cache and Amazon CloudFront is a pretty quick process that can have a huge effect on the speed and performance of your site. Don’t forget to check your site’s speed with a service such as Google Page Speed (which is free, and available online, as well as an extension for the Chrome browser) after configuring total cache. Hopefully you and your visitors will be quite happy with the results.

51 thoughts on “Speed up WordPress with W3 Total Cache and Amazon CloudFront (CDN)”

  1. Hi,

    How do you recommend updating/clearing the cache of the CDN from AWS? i.e: We had a major theme update, however the CDN still uses the old style sheets through all the subsites, etc. The only way I figured out to clear the cache is to set the cache TTL to a very low number but thats not really ideal? Is there a way to completely have the cdn crawl your site after a major update? This has been killing me. Thanks!

  2. Hi,
    Thank you for this great tutorial. It really helped me a lot to learn about Total Cache. I was using WP Super Cache before but W3C Total Cache is way faster.

    I have everything setup properly, but facing issues due to ‘Optimize Images’ in Google PageSpeed test. I am using Lazy Load plugins and my images are optimized as well. I am providing different versions of image to browser via SRCSET but browser is downloading large image instead of smaller one.

    Any idea how can I fix this? It is really effecting my website speed.


  3. Great post Dustin,
    I set up my site without problems.

    So I was surprised when my PageSpeed rating dropped from 85 to 34.
    The problem is oppression. The content on ColudFront not using compression.
    There is a setting for your CloudFront Distributions (Behavior/Compress Objects Automatically) where you can let AWS to compress content automatically.
    By default it was set to false. I changed it but there is no effect :(
    The second W3C has note on CDN page If using Amazon Web Services or Self-Hosted CDN types, enable HTTP compression in the “Media & Other Files” section on Browser Cache Settings tab.”” I checked it and compression is on.

    Do you have an idea why compression is not working? The logic says that it should be compressed twice, by w3c and by AWS.
    Without CDN enabled compression is ok.


  4. Hi Dustin , Thank you very much for this detailed article ! I just followed your instruction and set up my CDN successfully , very happy : )

    Thanks heaps!

  5. Thanks for the great article! It mostly worked just like you said. I couldnt find any help on Amazon and this was very helpful. Had to say thanks.

  6. I am trying to setup cloudfront cdn… but there is no “push” or “pull” option associated with cloudfront anymore???

    I am seeing “Web” and “RMTP”…

    Any suggestions?

    I am referring to this step from the tutorial…

    “Let’s get started with setting up Amazon CloudFront.

    1. Enable CDN. Enable the CDN on the W3 Total Cache General page. Select Amazon CloudFront from the pull-down menu (either pull or push).”

  7. Hi Dustin, thanks a bunch for the article. I never imagined Cloudfront was so fast and that cdn’s had this kind of performance jumps. Followed your article to the letter. The results are awesome. Scored 97/100 never got past 86 before even with total cache enabled without cdn it was 90. Now with cloudfront results look like magic. Thanks a bunch.

  8. Thanks Dustin,

    This is the first time I was able to follow a lengthy tutorial and have it work perfectly after completion. I do have a question though. For most pages wouldn’t it make sense to extend the cache time to something longer than an hour? Unless you are constantly updating your pages all day or they have a bunch of user created content, should it be extended to a day or longer?

  9. Thanks for this killer writeup Dustin. I was using WP Super Cache before simply for convenience but I can see Total Cache is way more robust.

  10. Hi Dustin, Thank you for the detail article. It’s been a great help.

    I have a question. What is the point of creating the bucket in S3 then? I’ve gone through the whole process and have my CDN active and working, however the S3 bucket is still empty.

  11. Just want to say “thank you” for this tutorial. What seemed like a very confusing setup at first (and one I’ve tried and failed at before), it turned out fantastic in the end.

  12. Thank you very much for this article it was perfect, and thank you to the poster who explained the bucket situation with with CloudFront Origin Pull.

  13. Hi there, thank you for the article – awesome. Does this mean that the wp-admin files will also be hosted on the CDN? As I’d love to be able to access the speed of the CDN when Im developing my site :)

  14. I have the same issue as Oaktowner – being penalized for dup content – quite immediately – after two days traffic from Google drops by 50%.
    Can somebody suggest a real solution to real problem as opposed to retelling setup instructions ?

  15. Hi Dustin,

    Thanks verry much for this extensive artikle!
    However the pull method with amazon cloudfront doesn’t seem to work with me.
    Images don’t show up in my posts, while they have the right url to them they are not found on the CDN (I suppose not pulled up to cloud front)
    This only seemd to start when I deleted my old bucket content on s3 from my previous cloudfront PUSH attempt.
    I don’t understand the connection cloudfront pull makes to s3, does it still use s3? (the origin is set to my site now, so it apears not to use the s3 bucket).
    The s3 bucket is however still there (empty).

    Do you think you can shed some light on this for me?
    It would be a great help if you’d know an answer!

    thanks in advance

    Michiel van Dijk

    1. Hi, Sorry for the bother, I solved it already:
      It was the way I created my cname in my hosts c pannel,
      I updated an old cname instead of creating a new one.
      When I created a new one for the cloud front name it worked instantly.

      Michiel van Dijk

  16. So I have been searching all over and can’t find a solution to my problem. I hope you or someone here can can help.

    W3 Total Cache and Amazon Cloudfront are causing duplicate content and cdn. aliases to show in Google SERPs which is a site wide penalization under the new Panda/Penguin.

    So it’s fine on my wordpress side but on my static files below the wordpress directory it is creating duplicate content in Google SERPs.

    For example, blog installation: http://mysite.com/blog/article/
    *note the sub dir blog

    Problem is when I search using the Google site:mysite.com query I come up with a ton of duplicate files from my aliases cdn and cdn1 being indexed.

    Such as http://cdn.mysite.com and http://cdn1.mysite.com/page.php

    These pages are NOT in the WordPress installation sub directory and they are static HTML/PHP files created by me.

    So they are indexed, out of my control because W3 & Amazon somehow cached them. I can’t just no index because it won’t work that way via robots and Amazon. Also they are already indexed so that wouldn’t help. It would just stop them from being crawled in the future.

    I have a rel=”canonical” in my static pages meaning they also show on the cdn. pages however Google still has them indexed.
    I can’t 301 redirect because again it’s a mirror of my static pages, not something I uploaded and have access to.

    So what say ye?

    Last thing I have tried was verifying http://cdn.mysite.com in Webmaster Tools and it’s pending for a URL removal. But I’m scared Google may see that as remove http://mysite.com as well. I shall soon see.

    Another thing is in W3 it says
    Never cache the following pages: wp-.*\.php index\.php

    Which are clearly in my sub mysite.com/blog/ but how would I get it to never cache mysite.com/page.php

    Pleaseee say you have answers. And if you have any questions feel free to email me.

    And the site in my name above is my site but not the site in peril. I did not list that one.

      1. I don’t know how?
        That was part of my question.

        As I said
        “Another thing is in W3 it says
        Never cache the following pages: wp-.*\.php index\.php

        Which are clearly in my sub mysite.com/blog/ but how would I get it to never cache mysite.com/page.php”

        How do I tell it not to cache php files in a folder above the WP installation? Where I hand coded everything.

        For now what I have done is verified cdn1.mysite.com and cdn.mysite.com in Webmaster Tools and did a complete URL removal. Seems to have worked because now site:mysite shows my site without all the duplicate cdn.mysite results.

        But there has to be a better way?
        Like telling W3 to leave stuff alone that is not in my WP installation.

        By the way, this is the site in question and I have an article about plugins linking to you guys as far as a complete guide to setting up W3.

    1. Well, to exempt page.php you simply add page\.php tot he never cache section…

      As for your duplicate content, I am surprised by that to be honest, I cannot understand how w3 total cache would replace URL’s that are not in your WordPress install folder…

      The only thing that I can think is that there is some fishiness in the .htaccess file in mysite.com which is doing a rogue rewrite…

  17. wow, thanks for the article. helped me heaps.
    once we create the bucket in the aws management console, once clicking the cloudfront tab, the status says ‘inprogress’. Does that mean it’s currently downloading all images from my site?

  18. Dustin you have written a fantastic tutorial on W3TC and Cloudfront

    Let me clarify the S3 bucket thing.

    S3 bucket is not needed for Origin pull option.

    CDN page of W3TC cache gives option to make a bucket because Origin Pull Amazon Cloudfront is NOT selected in General Settings page of W3TC.

    Select Origin Pull Amazon Cloudfront on “General Settings” page and then save all settings. That will change options on CDN page of W3TC.

  19. Hi Dustin,

    Just a note to say thank you so much!

    I have been at it for 3 days trying to get this tweaked.
    Your settings and advice were the only ones that worked.

    I did the Google speed test and came up with a 79.
    That is okay as the site is lightening fast!

    John Thomas

  20. Hey Dustin,

    I setup Cloudfront without S3 and W3 recognizes it fine and says “Test Passed,” but I can only access my page through the cloudfront domain address, but not through the actual direct domain name. If I just type in my regular domain address it seems to do nothing. Also, if I do go to the page through the Cloudfront domain address, the links on the page that are SSL do not link elsewhere. Also, the images still link to original wordpress host and not Amazon. Any ideas?


  21. Asa, W3 Total Cache gives you additional caching functionality not included in Quick Cache, as well as many more customization options, and also includes features such as minification and CDN integration.

    1. If you have a traffic heavy site, consider setting up a CDN with Total Cache and CloudFront. For smaller sites, the built in Quick Cache is sufficient.

  22. Dustin, this was very helpful. I’m setting up a site with Amazon S3 and Cloudfront for the first time, so I really needed someone to hold my hand as I walked through it.

    A couple of questions:

    1. When I went to add CNAME, there are little highlighted messages next to the name, like “for css only.” Do I need to pay any attention to those?

    2. I had it set up and working until I added the CNAME. Now it’s throwing an error message.

    Error: Domain name resources is not in distribution CNAME list.

    Is this just temporary as the DNS populates? Cloudfront shows it correctly, the host shows it correctly, and items are being uploaded into Cloudfront.

    Thanks much!

Leave a Reply

Your email address will not be published. Required fields are marked *