Thanks Steven, I didn't see that there was a reply earlier (no email that I saw).

I appreciate the thinking out loud.

Typically, here's how the loading time looks:

• WordPress generates the page content, typically about 0.3s

• Our API gets listing data, if not server (API) cached, ~4-5s, if server cached, ~0.9s - ~2s, if locally cached, ~0.1s

• Any other API requests run, but for the sake of this, let's say there's none (0s, though usually there's some other cached things, or if you're registered, some calls to record visit/ get notes/favorite status of listing)

I have timed my image checker on something with ~36 images (probably above avg image count, and inbetween my blocks of 10 checking), and it was ~1.3s - ~2.7s (and I added caching for it, so if we HAVE checked for the image count before, it gets cached in WordPress, ~0.1s. It seems like that getting responses from the server about images can also be server cached, so running the same query again without local caching takes as low as ~0.4s). Not bad, but because this is WordPress/PHP, there's no page output until everything is done.

So adding it all up, we get anywhere from ~0.5s (everything cached) - ~8.1s (nothing cached). So, quite a range, but my focus is going to be on reducing the top end. In this case, 8.1s for a page to START loading content is just too high. This is why I wanted to see about dynamically adjusting the photo count later. Most listings (if they have photos) are going to probably have more than 6 (our max thumbnail count), and by the time a user got to photo 7+ would have been more than enough time to get the correct photo count.

I'll have to play around with just refreshing the gallery, and see how (maybe) jarring it is, but I should be able to get what image they're on, and return them to that.

What you've suggested with CSS, is almost how it was originally before my initial edits, where the page would load, and JS on the page would send back to the site, which would send to the API to build the XML, and then back to the site and back to JS before the gallery loaded. This was also sent with several other AJAX requests, and usually was stalled until those finished first. When this was the behavior, we just used the JuiceBox loading icon (.gif) until that request completed.

On a quick note about the loading icon, when I was initially looking at reducing the amount of requests on our pages, I replaced the .gif file with a CSS animated loading icon, modeled after the .gif (saves some KB, and a request, just to share):

<style>
div#jb-custom-loading div.ds-spin-container{width:100px;height:100px;background:#000;position:absolute;transform:translate(-50%,-50%);top:230px;left:50%;border-radius:10px;border:1px solid #000;z-index:0}
div#jb-custom-loading div.ds-spin-teardrop{position:absolute;top:50%;left:50%;background-color:#000;display:block;width:12px;padding:3px 2px 5px!important;height:8px;border-top-left-radius:9px;border-bottom-left-radius:9px;border-bottom-right-radius:9px;box-shadow:0 0 8px gray;transform:translate(-50%,-50%) rotate(-45deg);margin:0;box-sizing:content-box!important;z-index:0}
div#jb-custom-loading div.ds-spin-hexagon{position:absolute;width:60px;height:34.642px;background-color:#fff;margin:0!important;padding:0!important;top:33px;left:20px;z-index:0}
div#jb-custom-loading div.ds-spin-hexagon:before,div#jb-custom-loading div.ds-spin-hexagon:after{content:"";position:absolute;width:0;height:0;transform:translate(-50%,-50%);border-left:30px solid transparent;border-right:30px solid transparent}
div#jb-custom-loading div.ds-spin-hexagon:before{top:-24%;left:50%;border-bottom:17.32px solid #fff}
div#jb-custom-loading div.ds-spin-hexagon:after{bottom:-74%;left:50%;border-top:17.32px solid #fff}
div#jb-custom-loading div.ds-spin-spin{-webkit-animation:ds-spin 4s linear infinite;-moz-animation:ds-spin 4s linear infinite;animation:ds-spin 4s linear infinite}
@-moz-keyframes ds-spin { 100%{-moz-transform:rotate(360deg)} }
@-webkit-keyframes ds-spin { 100%{-webkit-transform:rotate(360deg)} }
@keyframes ds-spin { 100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)} }
</style>
<div id="jb-custom-loading">
    <div class="ds-spin-container">
        <div class="ds-spin-hexagon ds-spin-spin"> </div>
        <div class="ds-spin-teardrop"> </div>
    </div>
</div>

As for performing a string manipulation on the configuration data, that's not specifically possible because all images that you request from the server are .jpg, whether they exist or not. You have to look at the image/ response headers to know if it's an SVG or not.

But as I mentioned, I'll likely just have to go back to either delaying the gallery from loading for a couple seconds after the page loads, or experiment with just refreshing the gallery when I know the correct photo count.

Thanks,
Tony.

Thanks for the reply Steven, off the top of your head, there's nothing in the JS that I could change so that if themeUrl == "false" for example, it doesn't try to load it?

I tried to follow the code, but it was a bit too much for me regarding how the themeUrl is processed/ loaded.

I was able to previously make a change that allowed me to inline the XML file that 'configUrl' looks for, and if it's the start of the XML file, simple read it from there, reducing a request to get the XML file (http://prntscr.com/lrt64k).

I tried looking at the

D.theme = J(D.themeurl, D.theme);

line, figured it was somewhere around there, but I don't really see where the stylesheet is being loaded.

Using http://0.0.0.0 from what I've seen would (to me, probably) be better than trying to load an empty file, as that's still an extra get request, which takes time and can stall other things.

I have tried with the current 1.5.1 Lite version, and it does appear to work there. So it looks like that this is a bug that existed in 1.2.0. We will have to see about updating, since what we're using is ~6 years old at this point.