• Resolved cjyabraham

    (@cjyabraham)


    I posted this issue some time ago. The performance issue seemed to go away at the time, however, now it is back. I’m tracing flickr calls taking 10s or more. See this screenshot from new relic which shows an average time of 3.6s over a certain time period.

    Anyone else having this problem and would it be possible to cache this call in the plugin?

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Sayontan Sinha

    (@sayontan)

    Considering that Photonic is designed to pull current information from Flickr and other sources always, caching will not be a part of its design. Additionally there are problems with caching responses from Google, and there are repercussions with respect to authenticated calls.

    That being said, when I loaded your site, it rendered in < 1s. Since I am on a 1Gig connection, I also did a test on https://webpagetest.org to account for a broader spectrum – even then it came back with good speeds. Are you using a cache? If so, why do you think a second cache would be needed? And if not, I am not seeing a problem with your site’s speed.

    As I wrote in the linked post, Flickr’s responses are generally pretty fast (definitely much faster than Google Photos and Zenfolio) – calls rarely go over 2s and are mostly below 1s. If you still want to avoid the hit on the server side during the initial page load, you can try using the JS loading mode (Photonic → Settings → Generic Options → Advanced → Loading Mode) – this will make sure your server is responding with your page’s contents fast, but will make the call to Flickr after your page is loaded. It will show a spinner while the call to Flickr is happening though, which some people don’t like. Additionally, if for some reason the calls between your server and Flickr take long, your tracer will continue to show slow responses, but your pages themselves will load faster.

    Thread Starter cjyabraham

    (@cjyabraham)

    Yes, I am using a cache and CDN on my site so the fast response you got is what most people would get. Still, the Flickr API has been so slow recently that, even though the site re-renders infrequently, it’s still setting off Appdex alerts in New relic. Additionally, when our admins go to the site, logged in to WordPress, they often have to wait several seconds for the page to load since they don’t get the cached version.

    I agree that generally Flickr API calls are fast but, for whatever reason, they seem to have been taking 5-10 or more seconds during the last few days.

    I was thinking a second cache for the Flickr calls might be useful as it could be set to refresh less frequently than my server cache and not at all for admins when they’re logged in… just an idea though and I didn’t think it all through…

    Ah, this JS loading mode is excellent. Since my gallery is further down on the page it might be fine for it to be delayed. I’ve turned it on on our dev site so you can see that it usually takes some time to load, right now at least: https://dev-lfeventsci.pantheonsite.io/kubecon-cloudnativecon-north-america/

    The AJAX call doesn’t seem to be getting cached on the server so each time you load the page the gallery takes time. Right now I’m seeing anywhere from 2-9 s to load the gallery via AJAX.

    Anyway, thanks for your response and this good option.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘flickr API slowness’ is closed to new replies.