Check out now the improved gallery:
There were tons of unnecessary "match row height" calls, which overloaded the CPU. Now I rewrote the whole matchHeight library, to watch only for the visible thumbnails and removed all the unnecessary refresh calls. I have also removed the matching on fixed height thumbnails with "tootltip" type captions.
This slowness is not about CPU overload like it was before. This is because of too many thumbnail loads started in short time. Now I made the code skip thumbnails that are shortly appear during the scrolling, and load only those that visible when you stop scrolling. Check out the video taken after a control-refresh.
Sorry, Laza, but it's not really better. I checked in a couple of different browsers, just to make sure I wasn't seeing some sort of caching.
I think the whole underlying concept of "lazy loading" is faulty. It appears that while you're sitting and staring at part of the page, the rest of the page isn't loading in the background, which is what a regular page of thumbnails would be doing. If it were, then by the time you started scrolling down, the rest of the images would already be there, and the response would be immediate.
If this is being done to save bandwidth, I say the hell with it. A page of thumbnails isn't using all that much bandwidth, anyway - it's no more than a few slide images would use. If you don't expect users to scroll down to the rest of the thumbnails, then why have them at all? Why not just show the user no more than 12 thumbnails, and not show him the other images until he's into the slideshow?
I partly agree, but the real CPU-hog this time was the poorly written height-matching routine. Regarding the CPU use it went down to some 1-2% of the previous version.
Also, when you want to go to the last picture and start the album there, the worst thing you can do is loading the thumbs in a progressive manner.
My routine follows the visitor, and loads only the visible screen with thumbs. The delay - you perceive as slowness - is necessary because if you don't wait a bit before loading the thumbs, just load everything that comes to the screen even for 1ms, the browser would load hundreds of pictures in a short time, which would temporarily overload the CPU, and would render the page unusable for seconds.
Pick any folder at https://jefftucker.org/. The lightbox script is loaded before anything else happens, so you're never in danger of getting a raw slide image - it just can't happen. The script is less than 100KB, so the visitor isn't sitting there forever, waiting for it. Well over 100 thumbnails then load from the top of the page to the bottom. You'd be hard-pressed to scroll fast enough to beat it to the punch.
Lazy loading and asynchronous JS strike me as being a solution in search of a problem.
I wasn't right about the thumbnails delay loading of the JS. In fact the document.ready event is fired before the browser starts downloading the images, so the skin code starts before that. Naturally, if there are too many thumbnails on the page, the process might slow down the skin initialization, but won't break it.
The asynchronous load of JS files is important they not block each other's execution. You have to make your libraries in a way so they can wait each other. The same applies to the JSON files, which you don't know in advance when they load. So everything in my code is chained: "once available then do this".
If you load everything through the HTML page, it takes much more time to load the page and construct the DOM. If we are talking about 100-200 images the difference is barely noticeable. This skin is based on JSON database however, which already holds all the information, so including the same information through the HTML page would double the traffic. If it wouldn't use JSON, then no "advanced" features would be possible: search, tag cloud, new image search.
I checked execution time on my fasted machine (Intel i7 6700K, Samsung SSD 950 Pro NVMe) with a local Apache2.
Apache2 starts up in 0.065 seconds, but pressing PageDown on the keyboard takes a second or two on an index page with 318 thumbnails total and 5 columns times 7 rows displayed.
P.S. When trying do reduce size of data1.json I unchecked Lightbox > Image date. But I can see them:
cameraModel":"DMC-TZ71","focalLength35mm":"172mm","resolution":"2560 x 1920","cameraMake":"Panasonic","isoEquivalent":400,"flash":"Flash did not fire, auto","focalLength":"31mm"
In the travel album (e.g. http://www.lazaworx.com/albums/Travel/2010/Thailand/index.html) if I clear the cache and load the page it takes some 1.6 seconds to be able to use the album the first time. When the main files come from cache (tree.json, common.css, the google font and all.min.js) the page loads almost instantly (690ms) and can scroll down in no time even though the current HTML page and the thumbnails have to be loaded new. In this case the most time is spent on Facebook's sdk.js (104ms) and jalbum's widgets (94ms) - even though no widgets are turned on. With Ctrl-refresh the DOM is ready in 1.6 secs of which common.css is alone 600ms, all.min.js is 580ms, tree.json is 380ms. (Note, this is a large album.)