Does Cloudfront impact SEO? Let’s set it up for a S3 static site and test it!

This is the fifth post in my series about static site SEO with AWS. In the last post, we uploaded the static site to Amazon S3 so that it’s publicly accessible on the web. In this post, we’ll move beyond static site basics and start to discuss how Cloudfront CDN impacts load speeds and SEO. Yay! We’re finally going to start talking about SEO!

This post will focus on a HUGE factor for SEO: speed. We’ll first take apart a few acronyms and then we’ll talk about how to make your website fast with Cloudfront CDN. Luckily it’s all pretty straightforward but with all things SEO: the devil’s in the details. Let’s get started!


How does Cloudfront CDN work?

It’s all about speed. Cloudfront is a Content Distribution Network (CDN) service offered by AWS.  If you are unfamiliar with what a CDN does or how they work, the concept is pretty simple even if the technology is pretty advanced. 

Cloudfront Edge Locations
Image from: https://aws.amazon.com/cloudfront/features/

Simply put: CDNs distribute your content from your web server (or in our case, an S3 bucket located in Ohio) to multiple other servers around the world called “edge locations.” These edge locations cache (store a copy) of your content so that it’s more readily available in different areas of the world.

This way when someone in Tokyo, Japan requests your website the requests don’t have to travel all the way to the S3 bucket in Ohio. Instead, the CDN intelligently routes their request to an edge location in Tokyo. This shortens the distance and reduces latency which means your website loads faster all over the world!

How does Cloudfront CDN improve SEO?

Speed matters, but CDN’s impact more than that when it comes to SEO. Search engines want to provide their users with relevant web content and an overall great experience. People hate slow websites so Google has to factor that into their ranking to ensure an overall good experience.

There is also another less obvious reason why search engines would favor faster websites: they have to crawl them. For Google, time is money when it comes to the energy cost of running the servers that crawl the web. If a website is slow, it actually costs them more to crawl that website than a faster website! That’s why CDNs and caching matter. (We’ll get to caching in the future.)

Search engine bots and crawling

There is also a third SEO benefit that comes from using a CDN. This is a bit of an advanced use case but if your site does a lot of Javascript client-side rendering, you can employ a CDN to deliver server-side rendered (SSR) pages to search engine bots.  This reduces the amount of time (and money) that search engines have to spend crawling your pages. 

Server-side rendering also means that a search engine doesn’t have to (or be able to) render Javascript just to parse your site’s content. That is a relatively expensive thing for a search engine to do. The benefit is that, since the search engine doesn’t have to spend so much effort to crawl and render your content, you will likely see a higher crawl rate which means you’ll have fresher content in search engine indexes. That’s great for SEO, especially for really large and dynamic sites. To do that, you’d have to use a CDN that offers edge functions like Cloudfront Lambda and Cloudflare Workers.

If you want to learn more about deploying Cloudfront for SEO check out this presentation.

But for our purposes, we are mostly concerned with flat out speed of content delivery. So let’s take a look at how a CDN improves speed.

Cloudfront CDN Example Speed Test 

In case you are like me and you don’t believe everything you read, here’s a side-by-side Pingdom website speed test to observe the effects of using the Cloudfront CDN. Both tests were run from Tokyo, Japan. The first test requests the new site’s homepage directly from the S3 bucket in Ohio and the second test requests the site after I’d deployed my site on Cloudfront. 

Test #1: From Japan to S3 bucket in Ohio

Pingdom test #1

Test #2: From Japan to nearest edge location when the Cloudfront Price Class was set to “Use Only U.S., Canada and Europe”

Pingdom test #2

Test #3: From Japan to nearest edge location when the Cloudfront Price Class was set to “Use All Edge Locations (Best Performance)” (so probably also Japan)

Pingdom test #3

I’m not sure why Pingdom didn’t render this last one…

In each of these tests, the most significant difference was in each request’s “Wait Time.”  Pingdom’s wait time is a measure of Time to First Bit (TTFB) which just means, how long does it take for the first bit of the requested resource to reach the browser. That’s a pretty critical metric though considering resources like javascript and CSS depend on the initial HTML document to load. 

Load time waterfall chart
Waterfall chart from Test #1

Here are the TTFB for the HTML document for each test:

  • Test #1 From Japan to S3 bucket in Ohio: 210 ms
  • Test #2: From Japan to the closest location in “U.S., Canada and Europe”: 114 ms
  • Test #3: From Japan to the closest global location (Japan): 6 ms!!
Cloudfront edge location speed test

As we can see, TTFB increases linearly with the distance the request has to travel. CDNs FTW!

Hopefully, this is enough to convince you that using a CDN is a great idea. Even if this test doesn’t directly prove an improvement in rankings, you can bet that your website’s audience will appreciate the decreased latency and improve load times.

Now let’s walk through setting up Cloudfront to deliver our static site hosted on S3.

Setting up Cloudfront CDN for a Static Site hosted on S3

Note: This configuration allows public read access on your website’s bucket. For more information, see Permissions Required for Website Access.

In the last post, we got a static site loaded to S3, so this post assumes you completed that. Otherwise, head back to and get your site loaded to S3.

S3 Static website hosting endpoint

NOTE #1:  It is really important that you use the static website hosting endpoint shown above for the next steps. That’s the one that looks like <your-bucket-name>.s3-website.<your-bucket’s-region>.amazonaws.com. This will be really important in the future.

NOTE #2: You should have already set up public read access for the bucket in the last post.

  • Leave the Origin Path blank. Your website should be in the root directory of your bucket.

NOTE #3: Don’t worry about SSL (HTTPS) or Alternate Domain Names  for now. We’ll come back to that in the next post.

  • For the Viewer Protocol Policy, select “Redirect HTTP to HTTPS” because it’s cool. We’ll get back to that later too.
  • Choose a Price Class that fits your needs. For low traffic websites, each option will be pennies but you can choose the best option for your needs depending on the geographies for which you want to optimize load times.
  • Leave all the other settings with their default settings.
  • Choose Create Distribution.

Now just sit back and wait! Cloudfront will propagate your content out to the edge locations that you selected based on the Price Class. 

Your website will soon be available soon via a Cloudfront URL that looks something like https://d1ix3q7vxbh8zd.cloudfront.net/ 

Speed Testing your Cloudfront Distribution

Want to run the tests mentioned above? 

  1. Go over to https://tools.pingdom.com/ 
  2. Enter the URL for your static site in your public S3 endpoint (<your-bucket-name>.s3-website.<your-bucket’s-region>.amazonaws.com) 
  3. Then try it with your new Cloudfront URL ( https://<blah-blah-blah>.cloudfront.net/ ) . 
  4. Play around with Cloudfront Price Classes and Pingdom locations to see how the CDN’s edge locations impact TTFB and load times.

Moving forward

I hope you have the tools to understand why CDN’s impact SEO and how to set them up. If you have any questions, please leave them in the comment section below.

In the next post, we will finally more the website to its own custom domain name with HTTPS!

2 Comments

  1. Suresh kumar Gondi

    Trevor, Great post. I did similar research too on my static site website.

    Do take a look at the bunnyCDN too. You can use the S3 Cache end point for the BunnyCDN origin URL.

    They just launched origin shield two days ago. It will pull the data from the origin server and will have a better cache hit ratio.

    In my testings, The bucket storages will have more DNS load time. But… to solve this, if we move to Digital ocean origin server for static site hosting with EasyEngine on it. That should speed up at the DNS level too.

    Always love reading your content and your geeky posts <3

    1. Trevor Fox

      Thanks Suresh!

      I hadn’t heard of bunnyCDN but it sounds pretty powerful. I’ll check it out. I’m glad somebody is looking at this deeply as well! 🙂

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.