If you browse for example to "Jedermannrennen" you have to wait a long time till all pics are shown and the links get active. If you browse to "RTF & Radmarathon" the browser can't the whole page and the links. This page is to large.
Does anyone have an idea how to get the pics on the index page smaler so that the browser could handle that?
Not directly related to this problem, but in looking at your site, I see that you have told Photoblogger to insert code in the <head> section of the HTML that is not valid. This section of the HTML should never include actual content that is to be shown on the page. In placing content in the <head> section, you have produced invalid HTML.
I think you should chop your folders into smaller ones. Not only photoblogger but any page with 1000 pictures will load slowly. On top of this Photoblogger calculates tiling, which adds even more processing time.
Also some of your folders load extremely slow, which can be either a server problem, or the invalid HTML, jGromit noted.
It's still the same. Anyway - now I've added the banner code in the Thumbnails not <HEAD> section. I would like to find a Header section with which I could add code to the top of the album just like I could do that with the Tumbnail section and the bottom.
I think that the problem with the long loading time is that the pages tries to show many large pics. I'll try it with smaler ones. That will take me a while.
1. The index.html is loaded by the browser. It contains only the first 6-8 thumbnails. Supposed to render in a few millisecs.
2. Photoblogger loads the /tree.json database which contains all the folders in the album. This depends on the size of the whole tree, but as it contains only the folders, it supposed to take some 20-200ms.
3. Photoblogger loads the current folder's all pictures from the data1.json file. This depends on the number of pictures in the current folder, approximately 1ms / image.
4. The skin renders the thumbnails without the thumbnail images, that is only the frame and the text. This wildly depends on the CPU speed.
5. The skin repositions all the thumbnails to fit them optimally. This could take also as much time as the previous step.
6. As you scroll down the visible thumbnails get loaded progressively.
From this it's clear the slow loading is not due to the large thumbnails, rather the high number of thumbnails per page. Naturally using too large thumbnails is a bad practice, because that will generate high traffic, but it will not affect the initial load time.
It seems your server limits the number of the requests and allows some 16 requests per 2-3 seconds. I guess it's done in an attempt to fend off DDOS attacks. However when the 15s timeframe is over Chrome gives up on loading any more items on a page, and finally no external libraries get loaded, and not even the skin's most important tree.json file.
I believe your service provider's setup is way too limited. It shouldn't choke on some 300 items.
I think I should implement progressive loading of folder thumbnails too. Originally I didn't think of the situation when a user has more than a hundred subfolders on a page.
I believe your service provider's setup is way too limited.
I agree completely. These days, with pages calling external libraries, even a fairly limited page might be making more than 16 calls when loading, and forcing those to wait is nuts - it's the sort of thing that Google will punish, for example, and that will annoy your site visitors.
And for a photo album, which will typically have dozens of thumbnails, it's completely unacceptable. Even if the page loads the thumbnails progressively, it might need all of those thumbnails to produce a thumbstrip for the first "slide" image.
Reliable, no-limits, no throttling web hosts can be had for less than $10 a month, the cost of a couple of fancy Starbucks coffees. There's no reason to scrimp.