It's all the javascript.
https://developers.google.com/speed/pagespeed/insights/
Will show you that nothing is minified, compressed, and that render-blocking JavaScript is really slowing things down. Not to mention that the site itself doesn't pass much validation so the browser is doing a lot of guesswork by itself while parsing what the server spat at it.
The theme is pretty, and honestly the best I've seen, for simple, professional themes, but the coding could be improved. Don't forget also that between the html, css and js, plus any image loaded on the page, is quite a lot of file size, no matter your connection speed. I would really like to see this theme redone with modern code (and instead of `` menus), validated, minified (maybe a script could be made to minify it all before it gets cached?), and perhaps even get some microdata in there.
I understand that the dev doesn't have infinite time or resources for this, just throwing in my thoughts. My whole ZP install is heavily edited, so I wouldn't even know where to begin helping, but if this thread gets going maybe we can all pitch in and make the dev's life easier to fix it up and make it load super fast.
I am not familiar with the theme but I just ran the site through the w3 validator. It is not valid but the "errors" listed are quite minor. Mostly the closing of self closed elements.
Somehow the static_html_cache is not working correctly on that site as otherwise it should be much faster after being cached.
[i]and instead of menus[/i] You mean and ``, right? A list is of course absolutely the right element for a menu itself. Nowadays you should use HTMl5 elements but it is not that it is actually invalid not to do.
The theme itself is on Github so I am sure gjr will welcome any help.
I found other galleries based on zpbase template. When I looked at source code generated in web browser I saw this:
for first gallery:
for second:
for third:
and i checked what my gallery report:
What's inside script that on my gallery it works worse than on others even when I have much more memory? is it really problem in template? maybe some scripts aren't optimized? I have almost 3000 photos in gallery is it that problem?
3000 images should not be a problem itself but not easy to answer for us. If the static html cache is running correctly you should be much faster normally (only if not logged in!). But none of the sites cited seem to use it as other wise there would be a note like this instead:
``
But try what Fretzl suggests in any case. Also take a look here if you haven't:
http://www.zenphoto.org/news/problems-with-albums-and-images
@fretzl
I disabled all plugin and nothing help.
@acrylian
so when i have running plugin static_html_cache I should have reported time for it in my code (browser code)? if yes that's really wired because I have static_html_cache enabled and nothing like you post not appear.
What I saw - when I run page without photos it loading fast and it doesn't matter is it on frontend or on backend
[quote]So as SilverSnake wrote template should be optimized...
[/quote]
SilverSnake appears to be indicating that the serving of the page is the issue (nothing is minified, compressed, and that render-blocking JavaScript is really slowing things down...) BUT, the times shown by those timers are server side times and totally independent from what happens on the browser.
Rather, something in the script is doing too much PHP processing.
I get today report from my hoster;
"You will find here the result of execution
of your site gallery.may.net.pl on the
server hosting you :
FINAL REPORT
--> Executed Successfully
First Test (strace)
CGI app load Time = 0.031 seconds
Total NFS Read File : 7 (took: 7.6e-05 s)
Total NFS Write File : 0 (took: 0 s)
Total NFS Stat/Access File : 86 (took: 0.00039 s)
Total NFS Delete File : 0
Total NFS Create Dir : 0
Total NFS Delete Dir : 0
Total NFS Lock : 0
Total TCP (HTTP, ...) requests : 0 (SQL ignored)
Total TCP (HTTP, ...) requests time : 0.000000 seconds
(SQL ignored)
SQL select requests : 0
SQL update requests : 0
Total SQL Time = 0.000 seconds (0)
Slowest SQL request (0.000 seconds) is
As you can notice on this result, the server executes
correctly your site without any slowness."
looks like problem solved - now I have response time below 1s.