The opposite of Lazy Loading with Limelight?

I’m looking for a way to do something that is sort of the opposite of lazy loading and wondering if there is a way to do this with Limelight. I want to wait to load the contents of a Lightbox until after the user clicks it. Why on earth would I want to do that? Surely it slows down the user experience, right? Well I have a series of high-resolution 360 spin photography and I want to put a lot on a single page. If it lazy loads them all, it really takes forever by the time it gets to the bottom ones. If the user wants to see one toward the bottom of the page first, then they have to wait. Here’s the page I’m working on.

http://falconry.org/exhibits/page-8/

At the time of posting, this isn’t lightboxed with Limelight yet, but I’m moving in that direction because it seems way more powerful than Mega Modal from Foundry.

Anyone have any suggestions on how I might accomplish this? With Limelight or with any other stack?

If you turn off Lazy Preload AND you use warehoused images then you will get exactly this behaviour - the image will only get loaded when the lightbox for that image is opened.

It has to be warehoused images and not local images dropped into the settings as RW will load those as page assets come what may.

1 Like

Ahhh. Well that would work if they were images. But they aren’t. They are these things.

http://360.falconry.org/1986_2_141_2000w/1986_2_141_2000w.html

They have to be loaded in iFrames.

Ah, OK. I’ve been working on Limelight 2 for a while and that is actually one of the things that it will do with iFrames.

Give me a day or so and I’ll see if I can fiddle that into the current Limelight for you without breaking lots of other things. Its not hard to do at all, its just the danger of interdependent things breaking.

3 Likes

That would be great! I’m really enjoying Limelight. I’m excited to see what you have in store for us with Limelight 2.

1 Like

I found another problem that is unrelated, but would complicate my using Limelight. Maybe you can see an easy solution to this one too. This one is harder to describe. Basically the 360 spin only runs in the modal if it is already cached. The first time you load the page, the modal shows the loading graphic and it clearly loads the 360 spin, but once it is loaded, the object won’t respond to click and drag. The only way to get it to respond is to refresh the page. Then it responds as expected. Now this is not only the case with the limelight modal. It also happens with both “Modal” and “Mega Modal” in Foundry. Curiously, however, it doesn’t happen in Foundry’s third option, which is called “SideSlide.” To be clear, it is only when it is loaded in these three modals that I’ve seen this problem. Directly in an iframe works perfectly fine.

Here’s a representative spin.
https://360.falconry.org/1992_4_1_2000w/1992_4_1_2000w.html

Now go to this test page:
https://falconry.org/page-14/

Here I’ve loaded up the 4 types of modals. Remember that this only happens the first time you load the page. Once it is in the cache it works perfectly in all of the other modals. It’s just frozen in whichever one you click first. This happens with all but the SideSlide where it works perfectly well.

See?

Unfortunately I can’t use the SideSlide because a) it isn’t the right look and b) it won’t do the delayed loading we talked about.

Is there a simple solution to this loading issue? Why does one of the options work, but the other three don’t?

It would appear to be because of this error from creator.js used on the page you are iFraming.

Basically, it can’t check whether it is full screen when the page loads (because it has zero size until the lightbox opens).

However, Limelight does work when the Lazy Preload option is enabled (I’ve just put your URL into a Limelight on my computer).

This is the same as many things that don’t work in light boxes, they will work with Limelight and the lazy preload as they get preloaded on the page properly, just hidden from view.

This therefore presents an interesting conundrum for you. Your 360 stuff will work but only when it is on the page as normal or in a Limelight with lazy preload. Either way, if you have a ton of them on a page then this is going to slow things down considerably.

Let me have a play with Limelight and I’ll see if I can make it work with load on demand using your link. Will this link stay available for me to test with?
https://360.falconry.org/1992_4_1_2000w/1992_4_1_2000w.html

1 Like

Yes. Thanks so much.

Actually, your page does work on initial load for me if I wait long enough (I have a pretty slow internet connection).
Here it is in Safari Private Browsing mode which has no cache and so is a good way to test.

… for what it’s worth …

When I use your test page link, I can confirm your description. When I empty the cache (from developer menu) and open the testpage, then in each of the three left modals the image loads, but freezes in the end. Wheras loading it from the right modal does not result in the freeze. (In Safari V14.1.2 on a Mac)

Sorry for the slow reply.

I did turn “lazy loading” on for Limelight but that didn’t change anything over here on Chrome, Firefox, or Safari (v. 14.1.1). The only things I can think of are

  1. that somehow it cached on your machine. Maybe you once opened it in a non-private window and now the cache is available everywhere. Once it caches, and you reload the page (even in private), you can spin them all.
    1b) if you don’t shut the private window but just refresh it, it still has cached the spin. It only clears the cache for a private window when you close the window and open a new one. Otherwise it behaves as cached in private mode as well.
  2. The other way is that, with the cache dumped, if you click the SideSlide version first, and it loads the 360 in that particular modal, then it works in all of them subsequently.

You can tell if it isn’t cached because you’ll see the loading graphic. If you don’t see that graphic, then it is definitely cached.

Middle of the night my time. Sorry if I’m slow to reply.

No, private browsing windows prevent this plus I confirmed that it was not loaded by using the source and network tabs in the dev tools. It was definitely not cached. In addition, it took nearly 10 seconds to load on my rubbish connection, when cached it was instant.

I have never clicked the SideSlide version at all, you said it worked so I ignored it completely as it must just be in page content.

During my 10 second wait I did indeed see the loading spinner.


Bottom line, it was absolutely quantifiably not cached and it did work.

Here is a video of it

You have way way too much content on that 1 page IMHO.

I think you should break that page into something like an overview introduction page that has 5 sub pages for each of the 5 topics in the introduction menu on the left of the current page. Then a good solution would be to use Poster2 stack in a blog/product type of grid showing a small image of each hood with a title. Poster2 would then dynamicaly load each item when clicked on, i.e. the content is not loaded until the user clicks what they want to see.

This would create a far better user experience and create better SEO for each hood. The current side menu doesn’t work well as screens widths go below a certain size.

Fascinating read BTW.

1 Like

So what would you like me to do with this? Are you still interested in the deferred load option for Limelight. If not, that’s fine but I’d like to confirm before I start on the changes.

So long as I can get the 360 to load properly the first time, like it does in that one Sideslide example, then I’d love to use Limelight with the deferred load.

I’d like to hear your thoughts on my video - that appeared to work but if you cannot reproduce that then there is little point in doing the deferred load. I’m still a little unsure of whether we are all talking about the same problem.

Oh. Sorry. I missed your video in my pre-coffee fog. It does load, but you can’t turn the 360 spin yourself so it isn’t interactive. It loads, then does one spin by itself, then you can’t turn it interactively until you load it again.

I appreciate the feedback and the idea. I really like the long page so getting it to work with Limelight is my first choice. If that doesn’t work out, I’ll try this. I really appreciate your reply.

Ah, I see, thanks. Now I know what to look for. I can see the JS error on their page that is caused by the issue of late loading.

I’ll see whether deferred load will solve it.

1 Like

I really appreciate your looking into this. Any sense yet for if it will work? I’m currently building the page as if it will, which maybe I shouldn’t be doing.