Hi,

I'm using Flickr module for a website for a dog breeder, so I am using Views to display the albums of the dogs and every new puppies. That means a lot of photos.
In my current website, which has only demonstration albums, I have only two pages with Flickr albums. Since my customer has 7 breeds of dogs, it will mean 7 pages of albums for the parents, and 7 pages for the puppies, classified by breed.

On click, every photo opens in Colorbox in "z" size.
Every album on my page corresponds to an album on Flickr. On Flickr, the photos are 2048px large.

In the "Parents" page, I have a first album with 16 photos, and a second with 11 photos.
In the "Puppies" page, I have four albums, with 4, 7, 11, and 6 photos.

I am using :
- Flickr
- Flickr block
- Flickr Field
- Flickr Filter
- Flickr Sets
- Colorbox

In the settings of Flickr, I chose :
- Updates every 4 hours
- Limit API requests 20
- Number of photos per album 30
- Default size s
- Use flickr.css
- Default size for single photos m
- Block settings : refresh random 23 hours, other 31 hours
- Number of photos per set 30
- Number of photosets per page 15
- Image size to open z

In the content types I have created (One for "parents", one for "puppies"), I have set the field "photo" to Flickr photo (widget : flickr photo), display as square. In both Views, (Parent view and Puppies view), there is a Grid of Fields with the Content : photos, displayed as square. Really simple.

The problem is that when I load the page for the first time, the Puppies page needs between 26 to 29 seconds to load, and the Parents page needs between 25 to 32 seconds. It doesn't seem proportional to the number of albums, since in the first measurement I had 26 seconds for puppies (4 albums), and 32 for the parents (2 albums), or neither to the total of photos (28 for puppies, 27 for parents)
When I load the page for the second time, it takes 2 seconds for both, and works perfectly.
And when I entirely close my browser and reopen it, it needs a lot of time to load the pages again.

It is the same on iPad too.

I am a bit concerned about it, because these albums represent the main part of the website, and will be visited everyday. I was wondering if we could increase the load speed ?

Thanks a lot.

CommentFileSizeAuthor
#13 field_cache-2403865-13.patch1.33 KBlolandese
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Category: Bug report » Support request
Related issues: +#2227669: Use the cache API for Flickr blocks (loads them quicker), +#2299833: More than 99 images per page?

I was wondering if we could increase the load speed ?

  • Check your cache settings.
  • Use cache warming and Boost to enhance site performance.
  • Restrict the number of images.
  • Restrict the size of the images, though the opening size ('z' in your case) doesn't impact the initial page load.
  • Get a faster internet connection (client side). We can be sure the images are loaded fast from the server side (Flickr's server). This is one of the main advantages of using a third party image host, apart from the ability to load content contemporarily from two different servers (yours and Flickr's).

When I load the page for the second time, it takes 2 seconds for both, and works perfectly.

That is because all the images are in your browser cache. The second time you load the page they don't have to be loaded from Flickr over the internet because they are still there.

Can you provide a link to your live site (here or by PM)?

Please set this fixed if your question is answered sufficiently.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Component: flickr (main module) » flickrfield
lolandese’s picture

lolandese CreditAttribution: lolandese commented
Status: Active » Postponed (maintainer needs more info)
Lydia DP’s picture

Lydia DP CreditAttribution: Lydia DP commented

MANY thanks for your reply, this is very kind of you and helpful.

• Use cache warming and Boost to enhance site performance.

- “cache warming”, if I understand correctly, addresses issues for the "first time a user accesses a page”, but in our case, all users are affected.
(As you point out, the only mean to have no noticeable delay is to rely on the browser cache.)

- We tried Boost (install -> enable -> clear all caches). Well, it completely solves the problem (load time down from 25 seconds to 3 seconds!).
It would still be preferable to understand what happens without the help from Boost: given its cache will expire on regular basis, it would be better if none of our visitor were to experience a 25 seconds delay...

• Restrict the number of images.

The number of images is quite limited.

• Restrict the size of the images, though the opening size ('z' in your case) doesn't impact the initial page load.

The images are thumbnails.

• Get a faster internet connection (client side). We can be sure the images are loaded fast from the server side (Flickr's server). This is one of the main advantages of using a third party image host, apart from the ability to load content contemporarily from two different servers (yours and Flickr's).

The client is on a 100Mbit/s fiber link and the rest of the site loads extremely fast. What happens is that everything loads very quickly, the browser then waits ~25 seconds for all the Flickr parts, and then the long-awaited Flickr thumbnails load almost instantly.
Could it be possible that the web server struggles to parse the data from Flickr or the resulting cache? This might explain why Boost is allowing such dramatic performance improvement?

• Check your cache settings.

It actually worked. I still have to load all the images in the Drupal cache, which takes around 30 seconds per page, but after that, every user can load it in 2 seconds.

Thanks again for your suggestions.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Title: Load speed issue » Improve the Flickr Field cache
Version: 7.x-1.6 » 7.x-1.x-dev
Category: Support request » Feature request
Issue tags: -load speed, -cache, -API request

We tried Boost (install -> enable -> clear all caches). Well, it completely solves the problem (load time down from 25 seconds to 3 seconds!).

Happy to hear your problem is solved by using Boost. This is why we suggest to use it on the project page. Static HTML delivery is maybe the most effective way to improve overall site performance and not only for the Flickr module.

Can you confirm that it are the Flickr Fields you had issues with? Flickr Blocks should render quick after we solved #2227669: Use the cache API for Flickr blocks (loads them quicker). Flickr Filter is acting on the node body (long text fields) that has its own cache already.

It might be good to implement a similar system that we introduced for Flickr Block also for Flickr Field. It boils down to using cache_set()/cache_get() inside the hook_field_formatter_view function. The generic cache_set() as used inside the flickr_request() function in flickr.inc does not seem to be effective enough (as turned out also for Flickr Block).

Turning this into a feature request.

Thanks for reporting.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Status: Postponed (maintainer needs more info) » Active
Lydia DP’s picture

Lydia DP CreditAttribution: Lydia DP commented

Sorry for the late answer.

Yes, I confirm that I have issues with Flickr Field, not Flickr Block.

Thanks a lot.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Issue tags: +ninja
lolandese’s picture

lolandese CreditAttribution: lolandese commented
Issue tags: -ninja +advanced
webservant316’s picture

webservant316 CreditAttribution: webservant316 commented

Concerning performance I notice a radical difference between Flickr field photosets and Flickr filter photosets. Flickr field photosets are so slow for me it is unusable. However, Flickr filter photosets loads the exact same photoset nicely. Of course the initial load for both is very slow, however subsequent loads for Flickr field continue to load slowly at the same pace, but subsequent loads of Flick filter load fast, probably from the either Drupal cache or the browser cache. Why the difference?

One idea is that for the Flick filter I set 'sort=unsorted' because documentation says that is faster. However, Flickr field does not allow the assignment of 'sort', nor the Flickr admin defaults. Perhaps the mandatory sort option for Flickr field is more time consuming.

Any other ideas? I may use boost to improve my speed, but I don't want to hide the problem before understanding why Flickr field performs so much worse than Flickr filter.

lolandese’s picture

lolandese CreditAttribution: lolandese commented

Using cache_set()/cache_get() inside the hook_field_formatter_view function is likely the way to go. See http://drupal.stackexchange.com/a/1311/19480. We did the same thing for Flickr Block that can be followed as an example. See #2227669: Use the cache API for Flickr blocks (loads them quicker): https://www.drupal.org/node/2227669#comment-8654129.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Issue tags: -advanced +Novice

Using the mentioned example this is not too difficult. flickrfield_field_formatter_view can be found in flickrfield.module.

lolandese’s picture

lolandese CreditAttribution: lolandese commented
Status: Active » Needs review
Issue tags: -Novice
FileSize
field_cache-2403865-13.patch1.33 KB

Attached patch caches the HTML markup of the rendered fields based on the photo or set ID and gets refreshed by default every 24 hours. We will make it configurable once confirmed satisfactory.

  • 1ae590a committed on 7.x-1.x 
    Issue #2403865 by Lydia DP, webservant316: Improve the Flickr Field...
lolandese’s picture

lolandese CreditAttribution: lolandese commented
Status: Needs review » Fixed
lolandese’s picture

lolandese CreditAttribution: lolandese commented
Status: Fixed » Needs work

Putting it in 'Needs work' status to make the refresh period configurable.