I've been looking at the timings of images loaded with ImageProcessor, and I'm seeing some things that makes me wonder.
On a site running
Umbraco 7.4.0
ImageProcessor 2.3.3.0
ImageProcessor.Web 4.5.3.0
We have an image that is 1920x761 and 161 Kb. Load that without any parameters, and it takes 70 ms.
Put width=1920 as a parameter, and then it takes 685 ms.
I'm guessing ImageProcessor needs some time to generate the image, but isn't over half a second excessive?
All other requests to the same image will be with the cached image. However, when testing, then it does still seem somewhat slower than just loading the picture
I think it's important for you to understand the implications of the difference of behaviour you are requesting.
In your first example you are adding no parameters.
That means that ImageProcessor.Web (It's really important to get naming correct here. There are two libraries) doesn't actually load and manipulate the image in any way. It is merely passed off to the static file handler and loaded like any other static resource.
As soon as you add a querystring multiple things happen.
The correct source of the image has to be determined. Is it local, remote, from cloud storage, etc
The query string is required to be parsed by all the IWebGraphicsProcessors to identify which one should process the request. (Protip: You can speed things up by disabling unused individual IWebGraphicsProcesor instances by installing the config package and removing them from processing.config).
The image is then loaded and decoded by ImageProcessor (ImageFactory class if you want to take a look) and its file type is determined.
Since there is only one parameter given, ImageProcessor now has to calculate the other dimension. If both dimensions match the original, the original image is returned, otherwise the image is resized.
The image is then encoded by the correct encoder, and cached to whatever caching mechanism you are using (usually the disk cache) and the request is rerouted.
The response headers are then manipulated to ensure that the image is cached in the browser.
Does all that make sense to you?
Now I'm sure there are places I could improve performance (remove legacy code, locking) in that mechanism but since I am not actively working on the library (I'm working on ImageProcessor Core now), and community involvement isn't as high as I'd hope it would be, I am not able to spend the time to properly do so.
In you second example there is either something terribly wrong with your setup, you have performed a refresh, or you have disabled caching in your browser tools. The browser will return a 304 for subsequent image requests once cached and not make the request to the server for the image. Those times should be either 0 or 1ms.
I notice you are using slimmage for your image requests. I would recommend you use the picture element or image with sourceset and let the browser handle making the requests for you. (There are polyfills available if you require them).
What are the specifications of your server? I get much faster load time (~200ms) for an image matching the first dimensions than that on my laptop. Intel M-5Y70 Processor @ 1.10GHz 1.30GHz with 8GB ram
And thanks for your detailed answer, and it absolutely maskes sense.
My comment about having too high expectations for ImageProcessor (or ImageProcessor.Web), was not to imply that it's shit, or anything like that, so I hope you did not take offence. If so I'll make it up to you with a beer @Codegarden if you're going again this year. :-)
We very much like ImageProcessor, and when pushing other platforms we work on to implement something similar, we always refer them to it.
But back to our issue.
Yes I've disabled the cache via the developer panel in Chrome as I want to get the same experience as first time visitors will see.
And yes we use Slimmage to serve responsive images.
Our server looks like this
2x Intel Xeon E5-2695 v2 @ 2.40 GHz 2.40 GHz (2 processors, 8 cores total)
16 GB RAM
So power should not be an issue either
The problem is, that Slimmage won't start to load the next image in a slider, until slide action to the next image has begun.
You can then see the image being rendered at the same time it slides in place.
I can barely see the problem, but the client thinks it is a huge problem, and the client is always right, right sigh
But the problem is really Slimmage, but I thought squeezing a bit more performance out of the image loading, could do it so rendering happened so fast, it wan't noticable by the client.
And when I saw the behaviour in my first post, I thought that my answer was there.
Preloading is complicated with all the parameters Slimmage puts on the image, and I can't really get it to work.
The picture element is only supported by approx. 55% of browsers in use, most notable is that is not supported in Safari untill iOS 9.3.
But I guess it could be an alternative to still serve responsive images, while fixing the rendering issue.
Thank you for your thoughts and input, I greatly appreciate it.
Questions about performance
I've been looking at the timings of images loaded with ImageProcessor, and I'm seeing some things that makes me wonder.
On a site running
Umbraco 7.4.0
ImageProcessor 2.3.3.0
ImageProcessor.Web 4.5.3.0
We have an image that is 1920x761 and 161 Kb. Load that without any parameters, and it takes 70 ms.
Put width=1920 as a parameter, and then it takes 685 ms.
I'm guessing ImageProcessor needs some time to generate the image, but isn't over half a second excessive?
All other requests to the same image will be with the cached image. However, when testing, then it does still seem somewhat slower than just loading the picture
http://prntscr.com/agsgph
...
On another site running
Umbraco v. 7.4.1
ImageProcessor 2.3.3.0
ImageProcessor.Web 4.5.3.0
We have a slider, where the images are all 1280x438 and around 150-300 Kb.
They take between 200-400 ms to load, and that's even after ImageProcessor has initially generated the images.
http://prntscr.com/agryfu
Retry http://prntscr.com/agrzv0
So I don't know if I have too high expectations to ImageProcessor, or if somethings wrong on our solutions.
Hi Michael,
I think it's important for you to understand the implications of the difference of behaviour you are requesting.
In your first example you are adding no parameters.
That means that ImageProcessor.Web (It's really important to get naming correct here. There are two libraries) doesn't actually load and manipulate the image in any way. It is merely passed off to the static file handler and loaded like any other static resource.
As soon as you add a querystring multiple things happen.
IWebGraphicsProcessorsto identify which one should process the request. (Protip: You can speed things up by disabling unused individualIWebGraphicsProcesorinstances by installing the config package and removing them from processing.config).Does all that make sense to you?
Now I'm sure there are places I could improve performance (remove legacy code, locking) in that mechanism but since I am not actively working on the library (I'm working on ImageProcessor Core now), and community involvement isn't as high as I'd hope it would be, I am not able to spend the time to properly do so.
In you second example there is either something terribly wrong with your setup, you have performed a refresh, or you have disabled caching in your browser tools. The browser will return a 304 for subsequent image requests once cached and not make the request to the server for the image. Those times should be either 0 or 1ms.
I notice you are using slimmage for your image requests. I would recommend you use the picture element or image with sourceset and let the browser handle making the requests for you. (There are polyfills available if you require them).
What are the specifications of your server? I get much faster load time (~200ms) for an image matching the first dimensions than that on my laptop. Intel M-5Y70 Processor @ 1.10GHz 1.30GHz with 8GB ram
Cheers
James
Hi James
Sorry for taking so long to respond to this.
And thanks for your detailed answer, and it absolutely maskes sense.
My comment about having too high expectations for ImageProcessor (or ImageProcessor.Web), was not to imply that it's shit, or anything like that, so I hope you did not take offence. If so I'll make it up to you with a beer @Codegarden if you're going again this year. :-)
We very much like ImageProcessor, and when pushing other platforms we work on to implement something similar, we always refer them to it.
But back to our issue.
Yes I've disabled the cache via the developer panel in Chrome as I want to get the same experience as first time visitors will see.
And yes we use Slimmage to serve responsive images.
Our server looks like this 2x Intel Xeon E5-2695 v2 @ 2.40 GHz 2.40 GHz (2 processors, 8 cores total) 16 GB RAM
So power should not be an issue either
The problem is, that Slimmage won't start to load the next image in a slider, until slide action to the next image has begun. You can then see the image being rendered at the same time it slides in place.
I can barely see the problem, but the client thinks it is a huge problem, and the client is always right, right sigh
But the problem is really Slimmage, but I thought squeezing a bit more performance out of the image loading, could do it so rendering happened so fast, it wan't noticable by the client.
And when I saw the behaviour in my first post, I thought that my answer was there.
Preloading is complicated with all the parameters Slimmage puts on the image, and I can't really get it to work.
The picture element is only supported by approx. 55% of browsers in use, most notable is that is not supported in Safari untill iOS 9.3.
But I guess it could be an alternative to still serve responsive images, while fixing the rendering issue.
Thank you for your thoughts and input, I greatly appreciate it.
is working on a reply...