Albums take to long to fully load

Hello Jacob
When we first asked, you said it was due to the random loading of the album covers.
You advised us to assign fixed album covers but this was a lot of work as we have over 7000 albums.
Shortly afterwards, you provided us with a development version which solved the problem but still maintained the random loading. Unfortunately, with each new version the problem came back.
We are now at over 50,000 photos on our website but there could be up to ten times that number in the medium and long term.
Wouldn’t a definitive automatic assignment of album covers be the solution?

Thank you for your help.
Michel
website owner

Basic settings -> Misc -> Item 3: Default coverphoto selection

select — most recently added — will be faster than random

Caching the childlist as in the dev version mentioned is still present in the current release.

Just a tip: If you do not track viewcounts, the cache files will live longer.

Would you like a coverphoto selection method that selects one random and set is as fixed?

The next version will have a checkbox near the default album coverphoto selection box on Basic settings -> Misc -> I -> Item 3: Default coverphoto selection, named Fix first found.

This checkbox only appears when the selection is set to — random — or to — random from (grand) children —.

When checked, (and the selection method on the album admin is set to default), the first time a random photo is found, it will be registered as the cover image. So, the next time the cover is requested, the cover image is already known.

You can afterwards change the setting on the album admin back to — default — to find a new one.

This should fix this issue

Thank you very much.
Your proposal does indeed seem to solve the problem.

Basic settings -> Misc -> Item 3: Default coverphoto selection
select — most recently added — will be faster than random

Yes, a little bit faster but the album covers are not loaded, or very little.

Thanks

Update to current version 8.0.05.004.

See the changelog:

Basic settings -> Misc -> I -> Item 3: Default coverphoto selection, has an extra checkbox named Fix first found. This shows only when a random method is selected. When checked, the first found will be registered as fixed cover image. The Reset all checkbox enables you to reset all the fixed coverimages.

• This reply was modified 3 years, 5 months ago by Jacob N. Breetvelt.

Hello,

“Random among son albums” is selected and “Fix first found” is checked.

The 3 albums :
https://www.photo-bondier-bergerac.fr/albums/1930-1939/
https://www.photo-bondier-bergerac.fr/albums/1940-1949/
https://www.photo-bondier-bergerac.fr/albums/institut-du-tabac/
always take 20 to 30 sec.

The same after “Reset all”.
If just “Random” selected, many covers are missing, not with “Random among son albums”.

Thank you.

Yes, and the second time it is 0.4 ms:

<!-- End [wppa type="album" album="5689" cache="inf" delay="yes"] /albums/1930-1939/ oc 2 0 queries in 0.4 ms. at 2:05 (cached) -->

Try without delay, may be a little faster.

If just “Random” selected, many covers are missing,

The albums that have no photos but only subalbums will have no coverimage.

I just dicovered that filling in the first found does not work.
Will be fixed in the next version.

To be more specific: the photo is found and registered as coverimage, but the information is ignored. So it did not reduce db queries.

Todays update fixes it; i have a testsite with 160k photos and 76 albums, and do the smame. The pages now load the second time and so on in less than 2 seconds, without caching.

Hello,

Basic settings -> Misc -> I -> Item 3: random with child albums & Fix first found OK
Version 8.0.06.00

Always more than 40 sec to load this page :
https://www.photo-bondier-bergerac.fr/albums/1940-1949/

Only 10 000 photos in this page BUT :
10 years albums x 18 child themes x 10 grand-child photo albums = approx 1800 albums for one WP page !!!

Have I to make one page per year instead of one page per decade ? I will have only 180 albums per page ?

Thank you

The page source tells me:

<!-- End [wppa type="album" album="6675" cache="inf" delay="yes"] /albums/1940-1949/ oc 2 2 queries in 9.1 ms. at 11:30 (delayed) -->

that it takes only 9.1 milliseconds to create the html for the album display, and:

<!-- End /wp-admin/admin-ajax.php?action=wppa&wppa-action=render&wppa-size=150&wppa-moccur=2&wppa-fromp=24934&lang=fr&wppa-occur=2&wppa-album=6675&wppa-cache=1&lang=fr&resp=1 oc 2 1 queries in 1.4 ms. at 11:30 (cached) -->

that it takes only 1.4 milliseconds to produce the cached content of the album display that is fetched by an ajax call, this starts when the framework of the page is ready.

The overall time for me to load the page on fgirefox with an empty browsercache is 11.3 seconds.

So, to my opnion its not creating the content that takes the time, but maybe the server and/or the internet connection is very busy/slow.

I recommend to remove the delay from the shortcodes because you do not need to see the bottom of the page before the album covers. This will help to show up the albums earlier.

Hello Jacob,

We removed the delay attribut from the shortcode and till now we have a pretty normal loading time.

Is this tag

<!-- End /wp-admin/admin-ajax.php?action=wppa&wppa-action=render&wppa-size=150&wppa-moccur=2&wppa-fromp=24934&lang=fr&wppa-occur=2&wppa-album=6675&wppa-cache=1&lang=fr&resp=1 oc 2 1 queries in 1.4 ms. at 11:30 (cached) -->

in the page source the only way to know the cache system is working or is there other ways to debug it?

Thank you

• This reply was modified 3 years, 4 months ago by rtahina.

Hello Jacob,

The page load time shortened after r1lita’s intervention but it became very long again (30 sec and more) shortly afterwards.
I intervened to split the 1940-1949 page into 11 pages which improved things a bit.
The other pages like https://www.photo-bondier-bergerac.fr/albums/1930-1939/ are still very long.
Do you have an answer for r1lita’s request for debugging?

Thanks`

The shortcode on page https://www.photo-bondier-bergerac.fr/albums/1930-1939/ has still the delay option. This causes a second http request to load the content, and hence a second latency time in the transmission.

Is i recommended before: tremove the delay=”yes” attribute in all shortcodes, but keep the cache=”inf” attribute in all shortcodes.