Why You Shouldn’t Serve Your Assets from S3

Amazon S3 is a sensible choice for storing your website’s assets in the cloud, but the benchmarks show that using a CDN is necessary to see any major performance gains.

If you’re reading this blog, you’re likely familiar with WP Offload S3, a plugin we offer that allows you to easily upload images and assets to Amazon S3. Storing your Assets on Amazon S3 is a great way to cut down on server space and keep your content in the cloud, but serving these assets from S3 isn’t always the best idea.

In this article we’ll be benchmarking three common ways to serve assets from your website – directly from the server, directly from Amazon S3, and from a CDN like Amazon Cloudfront.

About the Tests

Tests were run using GT Metrix. The website in question was using the default WordPress Twenty Sixteen theme, and the page tested contained 25 random, full-sized images sourced from Unsplash.

Each test was run three times from the same location to ensure consistency, and the load time of all assets on that page was averaged together to get a reliable load impact.

Loading from the Server

This is the most common method of serving assets and how WordPress does it out of the box. The assets in these tests were loaded from a 2GB Linode VPS, running NGINX over HTTP/1.1.


This is fairly typical of a website that is serving assets directly from the server, with an average asset load time of 523ms. Of course, this number will increase the further away the physical server is located, since the assets are only being served from one location.

Loading from Amazon S3

This configuration is consistent with a basic configuration of the WP Offload S3 plugin. The images and CSS/JS files are all served directly from Amazon S3.


Yikes. Despite being served from Amazon’s high-availability servers, assets loaded from S3 took an average of 760ms, 45% slower than the assets loaded directly from the server.

There could be several reasons for this. The 2GB VPS likely has an advantage in terms of sheer processing power, and the S3 bucket is mainly designed for storage, leaving content delivery to a dedicated CDN like Amazon Cloudfront.

Loading from Amazon Cloudfront

Now let’s see if we can speed things up a bit. By creating a Cloudfront distribution that pulls from the S3 bucket, we can tell WP Offload S3 to load the assets through the CloudFront CDN. This should result in more consistently fast loading times even in different locations due to the distributed nature of CDNs.


That looks much better. With an average of 431ms per request, the assets were tested as 43% faster than loading directly from S3, and 11% faster than loading from the VPS server.


This goes to show that while offloading your images and assets to S3 can be a smart move to save space or backup your content, it shouldn’t be thought of as a massive performance boost. Depending on your location and proximity to the server, loading from S3 may actually hurt your performance more than help.

If you want your website to load quickly for a larger audience, a CDN is a no brainer, and will often be the fastest option. Have you ran any of your own benchmarks or use a CDN to serve your assets? Let us know in the comments below.

About the Author

Matt Shaw

Matt is a WordPress plugin developer located near Philadelphia, PA. He loves to create awesome new tools with PHP, Javascript, and whatever else he happens to get his hands on.

  • Mike

    What about for serving large file downloads, like for downloadable video products? I was concerned about this so a while back, I posted a link to a big video file on a forum and asked people from around the world to download the file and to post their speeds. Although the file was in a USA based bucket, everyone around the world reported very fast download speeds. Since that test, I haven’t looked back. I’m going to use woo commerce along with their S3 plugin to serve large downloadable products.

    • I serve a couple of 1GB videos from S3 without issues – streaming is flawless.

      • Mike

        I’m not doing streaming, mine will be checkout, then download the file.

  • Rayduxz

    Can you add to this test CloudFlare infront of S3?
    That would be interesting to see.

    • If you are using Amazon for S3 anyway, CloudFront seems the most logical solution. I’m not a huge fan of CloudFlare. Especially their captchas for anyone using Tor Onion Router are massively annoying.

      • Rayduxz

        I’m not a big fan of CloudFlare either but it is a good solution to provide IPv6 support to AWS EC2 instances. Also you can set a rule to allow traffic coming from Tor, just whitelist the country code TOR (T1).

        • Иван Дьяков

          That would interesting comparison also because CloudFlare is significantly cheeper if you buy it from your hosting provider. Needs more pluses for S3 + CloudFront before buying WP Offload S3. By the way it’s additional year of support cost the same amount?

  • Kulali P

    Send a mailshot and welcome Xthousand visitors to your smoking server 🙂
    For me S3 solved the issue by “outsourcing” graphics and videos.
    That was before Cloudflare showed up…

  • Peter Shackelford

    Our primary concern is that our WordPress infrastructure needs to be scalable. Our codebase, db and assets are all separate. When we need to redeploy our codebase or scale horizontally, we don’t need to worry about files going missing or slowing down site scaling, as they are in S3.

  • Noam Eppel

    It depends on what you are optimizing for.

    If you are optimizing only for speed, loading from the disk may or may not offer better performance. (It depends on the use case).

    If you are optimizing for reliability and dependability, robust file backups, scalability, etc., S3 is likely a better option or S3 + Cloudflare.

    It is also important to note that benchmark numbers can vary widely due to network congestion. You can see how the author’s numbers vary widely in his 3 tests. You would have to run a benchmarking test at the very least 10+ times to get a reasonable indication of performance and do so under various server loads.

    • More thorough benchmarking is indeed required to be able to make any real conclusions. Good post though to counter the idea some people (like myself) might have that S3 is faster by default.

    • Dan Smart

      Yes, interesting conclusions, but I agree, a sample size of 3 is way too few to make any firm decisions on. The variability of the author’s results tests show that there’s a lot more information required. The end results may be the same, but i’d have much greater confidence in the conclusions.

  • pushplaybang

    this is sad link bait and isn’t a useful article for devs who may be new to this technology. you fail to mention, portability, scalability and reliability as factors, and the only point you seem to make it’s “remember to use a cdn”.

    this is what gives WordPress devs a bad wrap.

    • If we were into click baiting it would have been titled “We Served Our Assets from S3 and You’ll Never Guess What Happened Next!!!”

      • pushplaybang

        you realised you should use a CDN as well? There are a) no major revelations here, b) a statistically insignificant sample and c) no answer to “why you shouldn’t” in your article. If you had named it that, no one would have bothered.

        as I said – link bait. #fail

        • Luigi Nica

          Can you be polite and move on if you don’t appreciate? There are people who before reading the article might be under the impression that S3 solves everything. Like there are people who will figure out that they could combine Wp offload s3 + S3 + any CDN (Cloudfront, CDN77, KeyCDN).

      • Tamhas

        What did happen next?

  • It’s great to see everyone leaping to the defense of Amazon S3. We love S3. We have a product that marries it with WordPress.

    Unfortunately many of you have missed the point of this article and I think I know why. We assumed that the meaning of “assets” (in the context of a web development) was a generally used and well understood term. Clearly some of you aren’t familiar with the term so I’ll clarify.

    When we refer to “assets” we mean the files that would go into an assets folder when doing frontend development. They’re the files that are loaded automatically when a page loads: images, CSS, JS, font files, etc. Performance of these assets is extremely important as they affect the load time of your page which in turn affects SEO, conversion rates, etc.

    File downloads are not assets. Videos are kind of in-between and could be considered assets depending on how they’re used. Many of our customers still put their videos behind a CDN for better performance globally.

    So the point of this article is still very much valid. Yes, S3 is great and we still recommend using S3 to get your assets off your server for portability, scalability, reliability, etc. But don’t serve them from there! Put a CDN in front of them. There are people out there that think it’s fine to serve assets directly from S3 (I was one of them just a year ago) and this article was intended to educate those people.

  • Geraud Schmit

    Interesting article Matt.

    I have a static website hosted on AWS S3 with AWS CLOUDFRONT in front of it. And it seems that the IP address is not static (changing for every ping).
    Speed seems OK.
    It is 6 month old and I don’ see any traffic from Google (nada).
    Don’t you think that dynamic IP addresses could hurt SEO?