CDN's/Reverse Proxies

Hey, @aj,

Thanks for your kind words!

Well, the inability to work with a CDN is indeed the Achilles heel of the plugin! And did I mention I am greek, too? ??

Let me see, are you saying that you managed to achieve faster download times using full size images and a CDN? I do not mean to dispute this, but I find it a bit hard to believe in the general case. This might happen under specific circumstances, for instance if the orginal images are not too big or too many to begin with. Also, it depends a lot on the options one has set in the plugin settings, for instance having HiDPI support enabled or taking into account the landscape orientation of the device.

Anyway, this requires extensive testing.

You have understood correctly, I do have something in mind as a work-around for using the plugin with a CDN. The thing is that, when a website uses a CDN, it is the CDN that is reposnsible for actually serving the images. So, if the CDN were aware of the cookie that the plugin sets to the browser, then it could request/cache/serve the correct image size from the origin server. But I guess this would require quite a lot of configuration on behalf of the plugin.

Right now we are planning on testing such a configuration for Varnish and I believe we are close.

Let me know if you have any more thoughts!

Cheers,
Takis

PS: The plugin works with any CDN technically, but the results might be arbitrary, because the CDN does not request different images sizes from the origin server depending on the cookie that the plugin sets. So maybe it worked for you by chance!

Hi Takis,

Let me see, are you saying that you managed to achieve faster download times using full size images and a CDN?

“Full size”, as in the size they were applied at for a given page/post in WordPress, yes: iPhone 4 iOS 5.1, Shaped 3G (1.6 Mbps/768 Kbps, 300ms RTT).

AI wins the time to onload (i.e. “load time”) and fully loaded battle, which is to be expected. But, the test site making use of the CDN won the war with better numbers on the more important, viewport-relevant/above-the-fold performance metrics (e.g. Time to Start Render/First Paint, Time to Visual Completion, domContentLoaded), when the entire HTML response was being cached at the edge, which is obviously not possible sans a CDN.

AI clearly has the ability to shave off a lot of the ‘bottom end’ of the page load, but at the expense of the afore mentioned, more important ‘top end’ of the page load offered by the use of a (good) CDN.

Also, it depends a lot on the options one has set in the plugin settings, for instance having HiDPI support enabled or taking into account the landscape orientation of the device.

Ah, great point! I don’t actually know what these setting were in our (very limited) A/B test. I’ll find out.

The thing is that, when a website uses a CDN, it is the CDN that is reposnsible for actually serving the images. So, if the CDN were aware of the cookie that the plugin sets to the browser, then it could request/cache/serve the correct image size from the origin server. But I guess this would require quite a lot of configuration on behalf of the plugin.

Indeed. I imagine user agents could come into play, if one could figure out how to get that to cooperate in the grand scheme of things…

Right now we are planning on testing such a configuration for Varnish and I believe we are close.

Exciting! I’ll stay tuned.

Be well (and save Greece! – the world needs her),
AJ

Hi:

First of all, congrats on the plugin. Really useful.

I would also be interested in some form of CDN compatibility. How about a configuration option to serve scaled images with diferent URLs depending on the resolution? If this could be implemented, though not the perfect solution, it would force the CDN to cache diferent versions of the image as needed.

Regards.

@aj,

AI wins the time to onload (i.e. “load time”) and fully loaded battle, which is to be expected. But, the test site making use of the CDN won the war with better numbers on the more important, viewport-relevant/above-the-fold performance metrics

I see your point, I am totally with you on this, but it all very much depends on the specific circumstances. I am not so sure what the “general case” is here.

Indeed. I imagine user agents could come into play, if one could figure out how to get that to cooperate in the grand scheme of things.

Actually, it is all about one cookie! If the CDN could take that cookie into consideration and act accordingly then we would have a solution.

Thank you for your kind words about Greece, we appreciate it!

@railgunner,

This is a good point you are making!

But it takes some thinking in order to make it work in a transparent way. One could add a url parameter at the images via Javascript, but it would take a lot of effort to achieve the same for images in CSS backgrounds.

I will sleep on it. Tell me if you any other suggestions! ??

One could add a url parameter at the images via Javascript… I will sleep on it.

That would be great! Thank you for your efforts.

It really seems it could work. It seems too easy, to be honest, so I am trying to find out the gotchas.

One issue is indeed the case with CSS background images…

@aj and @railgunner, hello guys,

I hope you are well!

I am writing this message to inform you that the latest 0.6.0 version has added (experimental but usable) support for CDN/Varnish, etc. Maybe you would like to check it out!

??

Hey Nevma,

We gave it another spin with CloudFlare. Unfortunately, for a lot of the images, the original sizes as well as the ‘resolution specific’ sizes were being served. ??

Since you’re saying the new CDN support works with Varnish I’m assuming this is a CloudFlare cookie issue…

Some tests with the plugin activated:
https://www.webpagetest.org/result/150808_S1_MXG/
https://www.webpagetest.org/result/150808_GG_MY1/

Best,
AJ

Hello, @aj,

Thank you so much for testing, I was looking forward to that! I am looking at your tests and you are right. But I do have a couple of questions.

1. Why (and how) are some of the images served via the CDN, but others not? For instance “Request 3: https://www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png” is not served via the CDN, while “Request 28: https://cdn.wpfaster.org/wp-content/uploads/2013/06/dark-blue-textured-background-1920×1080.jpg” is!

2. Is it possible that the problematic images you mention were images in CSS backgrounds? Because these are not supported yet, as they are not part of the HTML of the page. However these should only be served in their original dimensions.

3. Also I am thinking that perhaps the Webpagetest.org machines might be so blazing fast in processing a web page, that the Javascript which changes the image sources does not have enough time to complete its job before the original images sizes begin to download. Thus some of the images get enough time to download in their original size.

You see, if I am not boring you with the technical details, what I am doing is to add a Javascript function to the DOMContentlLoaded event of the web page, where I retrieve all the images from the DOM and add a special url parameter with the resolution details to their src attribute. Actually I am removing and adding the src attribute anew. My tests so far with real browsers had shown that the browsers either do not have time to even start downloading the images or that they abort/cancel any image they have actually started downloading. Of course this makes the solution imperfect and I am aware of that, but it is supposed to have a very tiny bit of failure that I considered negligible.

What do you think on the above? Do you believe you could enable the plugin again in your site and let me test it myself for a bit? I know that might be too much to ask… ??

Oh, and I do not believe this should have anything to do with cookies or CloudFlare. Unless perhaps CloudFlare blocks any of the cookies a web page sets.

Cheers,
Takis

PS: I see a “ReferenceError: jQuery is not defined” in the console when loading wpfaster.org.

Just some additional thoughts.

It seems that there are actually some images like https://cdn.wpfaster.org/wp-content/uploads/2013/06/blurry-city-lights.jpg or https://cdn.wpfaster.org/wp-content/uploads/2013/06/dark-blue-textured-background-1920×1080.jpg and https://cdn2.wpfaster.org/wp-content/uploads/2014/07/Speed.jpg which are in -inline- CSS backgrounds and are not handled at all by the plugin. But that is to be expected!

About the other images, that actually seem to be downloaded twice, I am wondering if they are actually downloaded twice! Because when I test the plugin with Chrome Developer Tools, Firebug Developer Tools, Firebug, etc, I do see these requests, but I see them as “Aborted” or canceled, eg https://d.pr/i/1egO2 and https://d.pr/i/fYiG and https://d.pr/i/18dA8 and https://d.pr/i/13LOy (all these are from tests with an installation behind MaxCDN and Varnish). This has led me to believe that the images are not actually being downloaded after all. Perhaps the Webpagetest.org tool handles or reports these cases a little differently?

Hi again Takis,

1. Why (and how) are some of the images served via the CDN, but others not? For instance “Request 3: https://www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png” is not served via the CDN, while “Request 28: https://cdn.wpfaster.org/wp-content/uploads/2013/06/dark-blue-textured-background-1920×1080.jpg” is!

CDN (and CDN2) are shards, not actual CDNs. Shards in conjunction with some DNS trickery and SPDY allow more parallel downloads than would otherwise take place over HTTPS.

2. Is it possible that the problematic images you mention were images in CSS backgrounds? Because these are not supported yet, as they are not part of the HTML of the page. However these should only be served in their original dimensions.

No, CSS background images loaded as expected. You can see from the waterfalls in the tests (linked above) that nearly every non-background image loaded twice: the normal version and the version added by the plugin.

3. Also I am thinking that perhaps the Webpagetest.org machines might be so blazing fast in processing a web page, that the Javascript which changes the image sources does not have enough time to complete its job before the original images sizes begin to download. Thus some of the images get enough time to download in their original size.

That’s not quite how WPT works. WebpageTest.org is the only testing tool we recomend anyone using since it’s an actual, real test. There’s nothing synthetic about it: the above linked results are from real machines, on real browsers, on a real cable connection 5/1 Mbps 28ms RTT. Maybe you’re confusing the fact that our site is so fast with WPT doing something to make it that way ??

You see, if I am not boring you with the technical details, what I am doing is to add a Javascript function to the DOMContentlLoaded event of the web page, where I retrieve all the images from the DOM and add a special url parameter with the resolution details to their src attribute. Actually I am removing and adding the src attribute anew.

I saw that, yes. And perhaps that’s at least part of the issue: our site is highly tuned and hits domContentLoaded at, on average, right around 500ms potentially outpacing the plugins efforts. Again, you can see in the test waterfalls that the plugin is reloading the images but with the query string after domContentLoaded.

Do you believe you could enable the plugin again in your site and let me test it myself for a bit? I know that might be too much to ask… ??

No, sorry mate lol. ?? ??

PS: I see a “ReferenceError: jQuery is not defined” in the console when loading wpfaster.org.

There is a jQuery dependent inline script preceding jQuery (which is concatenated with other scripts at the bottom), so that shows up in Console. No biggie, everything works. ?? Thank you, though!

Best,
AJ

Hello, @aj,

Thank you for your thorough comments!

No, CSS background images loaded as expected. You can see from the waterfalls in the tests (linked above) that nearly every non-background image loaded twice: the normal version and the version added by the plugin.

Hey, that is kinda impossible because I am not doing anything to take care of them (so far). I am specifically targeting IMG elements in the DOM. How could this ever be? maybe they are used somewhere else in the rest of the HTML?

That’s not quite how WPT works. WebpageTest.org is the only testing tool we recomend anyone using since it’s an actual, real test. There’s nothing synthetic about it: the above linked results are from real machines, on real browsers, on a real cable connection 5/1 Mbps 28ms RTT. Maybe you’re confusing the fact that our site is so fast with WPT doing something to make it that way ??

I regard WPT as the best and most thorough testing tool and recommend it as well. I know it has real machines and browsers and so on. But it has no users on them. These machines have no real user load. However, this is not at all reason enough to neglect it!

You are right that the images that download twice have been downloaded the first time before the DOMContenteLoaded event. Which is totally natural and skipped my attention. The reason that I missed it is that it never happens in any of the tests I make in all machines and browsers I tried. However it always (!) happens in WPT tests. I wonder why!

I saw that, yes. And perhaps that’s at least part of the issue: our site is highly tuned and hits domContentLoaded at, on average, right around 500ms potentially outpacing the plugins efforts. Again, you can see in the test waterfalls that the plugin is reloading the images but with the query string after domContentLoaded.

Well, actually hitting the DOMContentLoaded quickly is good for the plugin because it runs right upon it!

Anyways, I am on the subject and I will keep you posted!

Cheers,
Takis

Hey Takis,

Hey, that is kinda impossible because I am not doing anything to take care of them (so far). I am specifically targeting IMG elements in the DOM. How could this ever be? maybe they are used somewhere else in the rest of the HTML?

We’re only including them once; then, once the plugin is installed, we get a second instantiation of most of the (non-background) images, e.g.

https://www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png

and

https://www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png?resolution=1920,1

*shrugs shoulders*

I regard WPT as the best and most thorough testing tool and recommend it as well. I know it has real machines and browsers and so on. But it has no users on them. These machines have no real user load.

Hmmm, not sure I follow or that I quite understand what “these machines have no real user load” means. If you run a test, you are the user. Absolutely no difference than if you were sitting at the physical machine or holding it in your hand: real device; real network; real upload/download speed; real packet loss; real last mile connectivity, you name it. If you’re talking about concurrent connections (?), there are probably more going on at once at any given time at each of the WPT test node locations than the average site gets. I’d have to verify that with Patrick, however.

Well, actually hitting the DOMContentLoaded quickly is good for the plugin because it runs right upon it!

Well, I’m just spitballing, mate. I know what the plugin is trying to do with CDNs, but would need to get into its guts to know how it’s doing what it’s doing lol. Which I very well may do, because I really think you’re on to something special with this and my curiosity is very much piqued.

I am on the subject and I will keep you posted!

Awesome. ??

AJ

Well, yes, as fas as I can see the image https://www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png is indeed present in your website’s HTML as an IMG element:

<img src=”//www.wpfaster.org/wp-content/uploads/2015/06/WpFASTER-logo-half-size.png” alt=””>

And this is the reason it is downloaded twice. Otherwise it would be a bit crazy because I honestly to nothing to CSS background images.

Hmmm, not sure I follow or that I quite understand what “these machines have no real user load” means. If you run a test, you are the user.

I am thinking that these machines are under some sort of “ideal” conditions. Nothing else is running on them. No user is clicking here and there opening tabs simultaneously or downloading their emails in the background, etc. And that is expected of course, otherwise these tests would not always be under the same circumstances and they would not be objective.

Connect this thought with the following:

there are probably more going on at once at any given time at each of the WPT test node locations than the average site gets

I have noticed that WPT queues tests, so that it does not run them all simultaneously. Again, this is expected for the tests to maintain standard conditions and objectiveness. Now I am not sure whether the queue in each WPT node is only big enough for one single site, but that wouldn’t surprise me! Again, objectiveness of the results bla bla bla.

but would need to get into its guts to know how it’s doing what it’s doing lol

Haha, yeah OK. Just keep one thing in mind: when the DOMContentLoaded happens then the plugin’s Javascript runs. So, the quicker the DOMContentLoaded the event, the quicker the Javascript will start and the better will be the chances that no original image is downloaded (hopefully).

Oh, also, need and curiosity are the parents of invention. I am sure some ancient Greek guy has said that some thousands of years ago…

??

Cheers,
Takis