Allow to bypass image size lookup / uncached pages slow.

The page render time went down from 1.1 min to 3 seconds.

Wow. More than a minute page load is indeed unacceptable. Even uncached. Just out of curiosity, how many image are there on the concerning page and what is the PHP version?

..if you have a large(r) number of images on an uncached page, it takes a really long time to load / render them.

If you use cache warming (built-in or other) a visitor would not never get to an uncached page. Nonetheless I agree with your proposal to offer the possibility to disable the image size lookup from the UI and/or do this client side with jQuery (preferred, e.g. http://stackoverflow.com/a/670433/523688).

As I see it, the image size is now used to set the dimensions of the surrounding div, and to determine if the caption should be shown?

Image not a square => get the size with getimagesize($img_url), needs 'allow_url_fopen' to be enabled => Fallback to cURL if fopen cannot be used or cURL is set to be used (that's your case) => Server settings don't allow us to determine the image width. Use the known longest side of the image for the width. Leads to horizontal white space on embedded portrait orientated images.

Help is highly appreciated. I review patches instantly, commit with attribution and/or can give Git access to commit yourself after a RTBC. My preference goes to a solution that helps also the less tech savvy.

In any case, thanks for reporting.

See also http://stackoverflow.com/a/6413645/523688.

Having given this some more thought, unless you have a super connection it seems almost impossible a page with over a hundred images loads in three seconds. Even Flickr itself doesn't render pages with that amount of images that fast over a normal connection. What image size are we talking about? Even with 150px thumbs it should be over 10MB. Are you really sure you cleared both site and browser cache before reloading the concerning page?

A more sustainable solution would be to #2096881: Use a pager on a embedded photoset in the body.

Inspired by http://stackoverflow.com/a/11652170/523688 we found another solution to have a caption with the same width as the image. Now we can get rid of the image size "lookup" all together. Furthermore it avoids an inline width property.

Be aware that it doesn't play nice yet with the sub-module Flickr Style but it should work as expected without that sub-module enabled.

I applied the patch (#7), and it did not work. There was no improvement with my photoset with 70 images. It still takes well over 2 minutes. The page load instantly when the images are cached.

Using a field that is set to a photoset.

@iStryker: Can you try the patch of #2403865: Improve the Flickr Field cache or the dev version of the module? The patch there has recently been committed.

When I applied the patch I was using the latest dev of 7.x-1.x branch. It would have the Flickr Field cache commit.

It might be important to know that the image size "lookup" is only done for images rendered as non square. As square images are set to be the default, you wouldn't notice a difference if not changed to another size.

NOTE:
It seems we lost the ability to set the image size of Flickr images of a Flickr Field somewhere. To open another issue if this is really the case.

I am using square images.

Are you saying for Flickr Field you cannot set the image size, therefore, it will always do a lookup (even if its square)?

No. It will not do the lookup for square images. That's why it's not resulting in a performance difference. Doing API calls for 70 images is slow in any case. The cache takes care of that though. In combination with cache warming you'll should be good.

While waiting for your reply, I tested it using Flickr Filter. I do not think its just the API. 70 phones took 4m0.3s (using wget). On reload it took 0m0.1s.

Was using [flickr-photoset:id=72157664222334235, size=s, num=70, heading=none]

Because dealing with images that take a long time to load after a browser cache clear in any case (especially 70 of them on one page), try clearing the site cache only to get an impression of that just used for API calls and server side processing.

Ideally we should use a pager on big collections of images. See #2096881: Use a pager on a embedded photoset in the body.

Any analysis help and/or suggestions for improvement are more than welcome. Thanks for your efforts so far.