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?
- How does Cloudfront CDN improve SEO?
- Cloudfront CDN Example Speed Test
- Set up Cloudfront CDN for a Static Site on S3
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.
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 is 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
Test #2: From Japan to nearest edge location when the Cloudfront Price Class was set to “Use Only U.S., Canada and Europe”
Test #3: From Japan to the nearest edge location when the CloudFront Price Class was set to “Use All Edge Locations (Best Performance)” (so probably also Japan)
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.
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!!
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.
- Go to https://s3.console.aws.amazon.com/s3/buckets/ and select the bucket that is hosting your static site.
- Click on the Properties tab
- Click on the Static website hosting box to open up the Static website hostings dialog.
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.
- Create a CloudFront web distribution. Select “Web” as the delivery method.
- In the Origin Domain Name field, enter the endpoint that you copied in Step 2.
- 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?
- Go over to https://tools.pingdom.com/
- Enter the URL for your static site in your public S3 endpoint (<your-bucket-name>.s3-website.<your-bucket’s-region>.amazonaws.com)
- Then try it with your new CloudFront URL ( https://<blah-blah-blah>.cloudfront.net/ ) .
- 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 move the website to its own custom domain name with HTTPS!