Amazon CloudFront has been advertising 1st year free. Not sure of the details but should be worth checking out.

Domain sharding and sprites are outdated performance tricks. Consider upgrading to HTTP/2.

Note that tools like Webpagetest.org give advice based on certain assumptions that do not always hold true. Whether your users will actually benefit from a CDN depends on many variables. But by all means test it. Just make sure you track the results using real user monitoring (RUM), e.g. through the Site Speed report in Google Analytics, because you should only be interested in how a CDN affects your users, not your scoring on some tool.

CloudFront (AWS) does have a Free Tier, but can get pretty pricey after that. Most CDNs offer a free trial period. Performance and options will vary. CloudFlare is another free option.

I use the free CloudFlare plan. I think it works all right for images, CSS and javascript.

HTML caching on CloudFlare is a failure. It really speeds up the site, but the problem is that they don't crawl the site. They serve my admin view of the website to the next visitor, so anonymous visitors could see my WordPress admin bar with my admin username. That was an epic fail. You need an expensive enterprise plan to have some bypass cookies avoiding that.

By default, HTML caching is not activated, and as for CSS, images, javascript, I think CloudFlare does a good job.

CloudFlare free, all the way. I tried CloudFront and MaxCDN and I like CF the best. They also provide other benefits for free that the others don't.

Does anyone know an affordable CDN that has a better implementation of HTML caching than CloudFlare? HTML caching can have a significant effect on page load times around the world. But as I wrote above, CloudFlare doesn't crawl HTML pages but instead serves one vistor's view of the page to the next visitor. This can make your admin bar visible to the next visitor.

Are there any CDNs at all that crawl entire sites in order to cache static pages, rather than caching views of these pages?

>>Domain sharding and sprites are outdated performance tricks

i agree, however in the case of the sprite, it is only a regular image, i fail to see why it would be a 'special' case, that required special instructions to work with a cdn.

maybe i'm missing the point? but i thought the point of a sprite is that the entire image is downloaded by the user (as a single file), then the css then positions or uses various parts of the image as required.

That is correct, topr8. The reason there are no instructions on using sprites is probably because they don't require special instructions, i.e. there's no difference (in implementation) whether you use a CDN or not :-)

I should add that while they're outdated performance hacks, they'll still work on HTTP/1.1 connections.

Here's the CSS code I use for the sprite (essentially):

.msgOn, .msgOff, (etc) {
 background-image:url('https://example.com/sprite.png')
}
.msgOn { background-position: 0 0; width: 22px; height: 20px }
.msgOff { background-position: 0 -20; width: 22px; height: 20px }
(etc)

Using Swarmify (the original choice for a CDN), they recommended modifying regular image tags like so:

<img data-cdn-src="example.jpg" src="https://assets.swarmcdn.com/images/1x1.gif">

Since that was just for image tags, though, and didn't specify CSS, I wasn't sure how to implement it. They replied back, though, and said that their system would work on any image, and that the data-cdn-src tag was optional... so that turns out to not be a big deal.

>> Domain sharding and sprites are outdated performance tricks.

This does concern me, though. I utilize both of these, so if they're outdated then what's taken their place?

I was just laughing earlier about how everything is cyclical. I don't know if you guys remember, but in the mid-90s we used progressing JPG so that they would load from top-down instead of waiting for the whole thing to load at once. Then, the popular trick became to break images into a bunch of small fragments, then use a table to place them all back together seamlessly. Then we moved on to sprites, so that we could go back to using one large image again. And now, we're moving back to something else... and my guess is that it's going to be using a lot of small images again, but with improved caching :-P

Does anyone know an affordable CDN that has a better implementation of HTML caching than CloudFlare? HTML caching can have a significant effect on page load times around the world. But as I wrote above, CloudFlare doesn't crawl HTML pages but instead serves one vistor's view of the page to the next visitor. This can make your admin bar visible to the next visitor.

Are there any CDNs at all that crawl entire sites in order to cache static pages, rather than caching views of these pages?

This is an excellent follow-up question, so I hope it doesn't get lost in the discussion of sprites. It doesn't apply to me since my site is almost entirely dynamic so I don't want the HTML pages to be cached, but I know that Swarmify only does pictures and videos.

Also, on the issue of Cloudflare, their free version says it's only for blogs and personal sites. Since I'm running multiple commercial sites, I don't think I would qualify for their free plan, but I don't expect enough of a performance boost to justify their paid plan.

Also, on the issue of Cloudflare, their free version says it's only for blogs and personal sites. Since I'm running multiple commercial sites, I don't think I would qualify for their free plan, but I don't expect enough of a performance boost to justify their paid plan.

Interesting. I don't remember any wording like that last year when I signed up. Maybe it was more than a year ago. The free plan would be fine for commercial sites as I have most of my sites on the free plan, although I do have 3 larger sites on the Pro plan.

Use HTTP/2 and you don't need to worry about sprites anymore.

This is what it says now:

We offer a Free plan for small personal websites, blogs, and anyone who wants to evaluate Cloudflare.

It still says unlimited bandwidth and websites, though, so it's probably fine, it just made me nervous that I'd start using it and then they'd flag me as a commercial site. And the fact that it required DNS changes scared me a little, that leaves some room for ID-Ten-T errors on my end.

Running through the DNS, though, is probably faster than Swarmify. Their system runs by plugging a few Javascript lines in the header.

>> Use HTTP/2 and you don't need to worry about sprites anymore.

I know naught of what you speak :-P I'm going to have to research this. I'm rebuilding everything in HTML5, anyway, so now's the time to change if I'm gonna (have|want) to do it in the near future.

Their system runs by plugging a few Javascript lines in the header.

Unusual... Have you checked if Swarmify is actually speeding up your page loads? They seem to be more video-oriented rather than a "regular" CDN.

>>Domain sharding and sprites are outdated performance tricks.

i think the point is to do with concurrent connections, by using a sprite you gained performance by using only one 'connection' to download multiple background images and so forth. as you are limited to the number of concurrent http connections (to the same domain) in http/1

whereas the modern theory is that with http/2 you can have a great many concurrent connections (to the same domain) so there is no bottleneck.

... things do change a lot with time and i do remember chopping up images and reassembling them in a table!

whereas the modern theory is that with http/2 you can have a great many concurrent connections (to the same domain) so there is no bottleneck.

There's only a single connection, actually, but it can carry multiple resource at the same time, so on a HTTP/2 connection the overhead of domain sharding (DNS lookups, TCP handshakes) and image sprites (maintenance, CSS rules, rendering) will actually slow you down. It was fun to experiment with all those performance tricks, but I guess this is better :-)

Unusual... Have you checked if Swarmify is actually speeding up your page loads? They seem to be more video-oriented rather than a "regular" CDN.

Unfortunately, Rob, I wasn't able to do a real test. I've had it in my sandbox and put it on one of my larger live sites last night, but after a few hours I discovered a bug so I had to take it down. So I haven't had it running long enough to see if it made any real impact.

According to [u]their[/u] stats, though, I saved about 85% of the bandwidth used on images during that period, so that's something.

The script that didn't work is home-rolled:

<script>
function changeMain(img, width, height) {
 var msg = "<img src='" + home + "/photos/" + img + "' width='" + width + "' height='" + height + "' border='0'>";
 document.getElementById('classifieds_img').innerHTML = msg;
}
</script>

<div id="classifieds_img">
 <img src="$home/photos/1021264_0.jpg" width="275" height="155" border="0">
</div>

<div class="classifieds_thumbnails">
 <div class="left" 
 onClick="changeMain('1021264_0.jpg', '275', '155')">
  <img src="$home/thumbs/1021264_0.jpg" width="75" height="75" border="0">
 </div>

 <div class="left" 
 onClick="changeMain('1021264_1.jpg', '275', '155')">
  <img src="$home/thumbs/1021264_1.jpg?h=20170203034317" width="75" height="75" border="0">
 </div>
 <div class="clear"></div>
</div>

I wrote that several years ago, but I think it's pretty simple: there's a large image on the top, and thumbnails underneath. You click on a thumbnail, and it replaces the large photo with the larger copy of the thumbnail.

For whatever reason, the large image and thumbnails would load just fine, but when I clicked on the thumbnail, the replacement image wouldn't show. There was no error or anything, and "inspect element" would show that the image should have been there... it just didn't show.

So far they've replied to my questions within 24 hours, so I'll send this one to them, too. If it's something that can be fixed easily then I'll go back to testing them and post the results.

Where/how do you define $home (in the HTML) and home (in the Javascript code)?

If Swarmify works by replacing your image URLs with the CDN's on-the-fly, it may interfere with your code.

Sorry 'bout that, Rob, I should have been more clear. $home and var home are both defined earlier in the script, and both are simply https://www.example.com.

Swarmify replied to my support request very quickly (at 10am this morning, 5 hours after I sent it), so that's pretty cool. I'll keep you posted if it's resolved, and then I can give better feedback on whether it has a significant speed impact.

I can say, though, that at least one person confirmed that they saw a notable speed improvement during my short test run. It's not documented, just an observation, but that's enough to make me move forward.

If you use Google Analytics, use the Site Speed report to gauge how the changes affect your users. It's under "Behavior", and I generally use the "Page Timings" report, more specifically the "DOM Timings" report with the "Avg. Document Content Loaded Time" metric selected, because I find it gives the most accurate view, excluding the loading of AdSense ads, for example (which I have no control over). Optionally, if you want more data or don't have many pageviews*, you can increase the sample rate [developers.google.com].

* Since it's a peer-to-peer system, if you don't have many concurrent users, Swarmify is probably not a good pick:

Swarmify only works when there are peers to retrieve data (videos and images) from. If you are the only person on your site then there are no other peers to download content from. Please makes sure that there are multiple people on your pages at the same time.

(I'm not sure it would beat a good traditional CDN on performance either -- since now you have two parties with frequently possibly high and varying last-mile latencies -- but maybe on bandwidth usage.)

If you use Google Analytics, use the Site Speed report to gauge how the changes affect your users. It's under "Behavior", and I generally use the "Page Timings" report, more specifically the "DOM Timings" report with the "Avg. Document Content Loaded Time" metric selected, because I find it gives the most accurate view, excluding the loading of AdSense ads, for example (which I have no control over).

Cool, thanks! I'll have to be able to test it for at least a day, though, to be able to make any type of comparison, so maybe after this Javascript problem is resolved.

Since it's a peer-to-peer system, if you don't have many concurrent users, Swarmify is probably not a good pick

My largest site does have a lot of concurrent users; at one point last year, we had close to 2,000 users per second! It's more common for us to have around 100 or so on the site at once, though, that was just a big day.

Would Cloudflare (running through the DNS) have the same condition?

No, Cloudflare is more like a traditional CDN, not a peer-to-peer system. They have one of the biggest networks of edge servers, and a presence on all continents, even Africa. I don't use them myself because running dynamic, personalized and oft-changing web pages through a CDN slows down my time-to-first-byte (TTFB) -- doesn't feel as snappy.

Well, just a few points to update you guys:

1. Swarmify replied after a few days about the Javascript issue. I feel like they went above and beyond, completely rewriting changeMain() for me to utilize their system! I thought that was pretty cool.

2. I began using Swarmify at around 3am on 2/14/17, and I made a post on my message board to let everyone know that I had made some speed updates, and to please let me know if they saw an improvement. I had several responses that, yes, pages were loading much faster than before.

HOWEVER! I can't verify that with actual numbers. Comparing 4 consecutive days with very similar traffic, Analytics shows no real change at all in average load time:

// Before Swarmify
2/12/17: 6.86s
2/13/17: 6.49s

// After Swarmify
2/14/17: 6.39s
2/15/17: 6.59s

Buuuuut, that's just an average, so I don't know if that's the right way to compare.

Looking at my server, I see that bandwidth usage went down considerably:

// Before Swarmify
2/12/17: 4.80Mbps
2/13/17: 4.11Mbps

// After Swarmify
2/14/17: 2.71Mbps
2/15/17: 2.37Mbps

So users are reporting a noticeable improvement, and I'm using less bandwidth, but Analytics doesn't reflect the change. So I don't know if the perceived change is just in their head? Or maybe the bandwidth change is unrelated to load time?

Also, I went through the steps to use Cloudflare, but then at the end it said that I had to change my nameservers at the domain. This is a concern because my domain acts as the nameserver for a lot of client sites that I host, and I can't risk any errors being passed on to them.

If you guys have any input on that, I'd be interested to hear it!

The bandwidth change just shows you offloaded traffic from your servers to "the swarm". More requests to Swarmify = fewer to your server = lower bandwidth. This is to be expected when you switch to a CDN. Unfortunately, CDN traffic tends to be much more expensive.

Averages are a good way to compare performance because you want to know how your changes affect all your users, not just a few. Did you only ask your users to "let [you] know if they saw an improvement", or also if performance declined? You don't want to be selective in the responses you sollicit :-)

As I wrote earlier, use the "DOM Content Loaded" statistic in Analytics instead of "Avg. Load Time" to get a better view of how your main content performs for your users, excluding any third-party content such as ads. You'll also need to give it a few more days to get a good picture (especially with CDNs, since their edge servers first need to cache your content).

If it's just small, static content you're optimizing, a "regular" CDN is likely to outperform Swarmify, and be more reliable as well, in the sense that a nearby edge server will always be available, whereas with Swarmify you depend on nearby concurrent visitors as well as their (consumer) bandwidth and latency -- and the last-mile latency to the user's home is often the worst. Swarmify is mostly marketed for video because those are large downloads that may benefit from having peers as close by as possible.

Cloudflare does require a change of nameservers, but you'll still be able to manage your DNS records and configure records so that traffic does not pass through Cloudflare servers. But if you're just testing the CDN waters, I would recommend getting a free trial somewhere and then just use a CNAME or the designated CDN domain.

Tip: You should consider your traffic first and plan accordingly. If you have traffic primarily from the same country the server is in it may not be worth the small benefit for a small number of visitors. You are adding an additional failure point which can and does have occasional issues regardless of which service you pick, you have to remember that too.

You should also exhust all other ways of improving performance such as by using a proper caching setup, minimizing the use of non-essential plugins and addons and cleaning up any major code-related blocks or issues before deciding if a CDN is needed too.

Low traffic sites can typically get away with placing the images in a sub-domain instead, or simply leaving them on the same domain. The benefits really don't kick in until you actually receive a good amount of foreign traffic(related to server location) and until that point cache will provide much more noticeable improvements.

Just to keep you guys updated... I turned off Swarmify today :-(

I do note that I was saving considerable bandwidth, but Analytics never showed an improvement. Or if so, it was negligible. But I've had 3 people complain that images that used to load weren't loading anymore.

All 3 of the people that complained were using Internet Explorer and claimed to not have any add-ons installed, but I couldn't duplicate it on my end so there was something else causing the problem... an antivirus, maybe, or possibly even a spyware infection. But 2 of them claimed to have tried on multiple computers, which is hard to believe but neither of them had a reason to lie.

And as you know, 1 call equals a billion people (haha, that's a Family Guy quote for those that don't know).

Swarmify has excellent customer support, but I can't risk making the site unusable for some users, especially without a notable change in page load time.

Are you going to try a "regular" CDN?

Probably, but not immediately... there's no way of knowing whether I've lost users due to the slight issue, so I can't risk another problem that runs them off. So I'll have to wait a few months.

Even then, I'd like to find one that I can just change a CNAME instead of the entire NS, like you suggested before. I might email CloudFlare and see if there's a way I can do that with them.

Cloudflare is one of the exceptions when it comes to that. Most CDNs work with CNAME records.

If anything I think it's probably the peer-to-peer concept of Swarmify that may have broken your site for some users. Consumer internet connections are unreliable and I can imagine this can cause issues. CDNs have a large network of stable, well-connected servers around the globe that are pretty much guaranteed to work.

Consider upgrading to HTTP/2.

Most shared hosting doesn't support HTTP/2. The 3 hosts that I mange sites on have said they have no plans on doing so (they will of course eventually.)

This is where most CDNs currently have the advantage.

Siteground supports HTTP/2 in all their shared hosting plans. But they have Cloudflare integration, anyway.
1&1 mentioned some time ago that they would migrate to HTTP/2 servers soon, but I don't know what the current status is.