Parallelize downloads with one server by using apache

Question

People seem to be pushing all of this as a way to sell CDNs, but surely it can be just done with apache. If browsers can only download 8 files at a time from website.com, why cant I just setup 2 random subdomains that point to the same location and randomly serve images from these subdomains instead of the same domain? For example

<img src="https://website.com/images.img1.jpg">

will become

<img src="https://static1.website.com/images.img1.jpg">

Under the hood, both are pointing the same file on the same server in the same folder, but it will let me parallelize the downloads without having to spend any money. What is the downside to doing this, because it seems to make perfect sense to me?

If pointing the subdomains at the same server could cripple apache or something, why cant I instead rent a second server, install apache here, store all my images on this server and point a few different subdomains at this server. I can then outsource image serving and use 5 different subdomains if i wish. Its not a CDN of course, but it seems like a cheap way to achieve faster page loading without the complication of messing with CNAMEs and CDN providors.

Answer 1

Yes, this is a perfectly valid solution to the problem. It also covers the "use a cookieless domain for static assets" speed recommendation, if setup correctly. This won't add additional server load, as the requests are being served by the same server either way.

It also makes it easier to move to/from CDNs at a later date, since you can change that hostname to point at the CDN without having to change your templates (as long as the paths will match).

The current connection limits by browser can be seen here: https://www.browserscope.org/?category=network (look for "Connections per hostname"). The data for Chrome seems to be missing, but I believe it used to support up to 6.