Album selection in Google Photos fails when LOAD MORE is needed.

There is a setting for this: Photonic → Settings → Google Photos → Chain queries. This setting is explicitly meant for this requirement.

It actually slows things down, and quite significantly, depending on the number of albums you have.

Behind the scenes, the code invokes web-service calls in a sequential manner. There is no way to make the calls in parallel, as Google doesn’t have a way to paginate the data; rather Google provides a “token” with each page, which you have to use to retrieve the next page.

If you have a large number of albums (> 500), this can add a hefty load time. E.g. in your case, your page currently loads in ~3s at my end. A lot of this actually goes into the round-trip call to Google. From what I can remember with my initial testing, with each additional call to Google, this increases by about 0.7s.

There is another facet – rate-limiting and quotas. Google has rather aggressive and low quotas, and each time you fetch a new page, it counts towards your quota usage. Combined with the fact that each page reload, and fetching each photo also counts towards your quota, this becomes a problem for many users.

Does the quota hit when visitors are at the site viewing photos?

Yes. Google has 2 types of quotas – an API call quota (10,000 per day), and a media access quota (75,000 per day). What I am referring to hits the first type. Now, if you display an album and show 100 photos from it, that counts as one API call (for fetching the album) and 100 media access calls. But if you display a group of albums, you only invoke the API call quota upon page load. For your scenario, there might be 2-3 API calls with each page refresh. When you explicitly click on one of the album thumbnails, that’s an additional API call per album clicked, plus the calls for all the media items in it. Unnecessarily complex – I know.

And does the PHP vs. JS options change this at all?

No. The JS option is often preferred if you want your page to load faster. It gets you better scores for time-to-first-byte and quite a few other SEO metrics… but it loses you points if your photos are above the fold and cause a “Cumulative Layout Shift”. I have optimized things to the extent possible, but I periodically revisit these to make improvements (e.g. this one is in my to-do: https://wordpress.org/support/topic/mosaic-layout-under-fireofx/).

The PHP mode is preferred if you have caching enabled (which you cannot do with Google Photos – their URLs are non-cacheable). It also gets you searchable content, since your page’s content is all coming from the server (unlike the JS mode, where some of the content is coming from the front-end via AJAX).

For Google Photos, JS mode is the way to go. For other platforms, it is your call based on the advantages and trade-offs that I mentioned above.

Also is there in option when you retreat all albums to specify a sort order? Most recently modified would most likely put the ones desired at the top of the list. I use that sort in Google Photos.

I deliberately don’t offer options that are not natively supported by the API. This keeps the focus on performance. There are rare cases when I go beyond this, e.g. the “query chaining” feature above (mainly instituted because Google will not let you pull more than 50 albums in one go, unlike Flickr or SmugMug), or for Zenfolio, whose API is too useless to do anything meaningful.

Google’s API doesn’t offer any option to sort. The feature might be there in their app or website, but their API doesn’t have it. Though it might seem trivial, sorting for Google Photos is one of the worst nightmares if you have more a large number of albums. Basically, I will have to do the query chaining to first pull all the albums, then run a sort, then paginate.