Images loading delayed

Yes, quite some options to preload images. All depends a bit on the setup of your project. If you check http://community.trivantis.com/shared-content/lectora-player-with-page-2-page-transitions/

this sample i did on transitions, you see that no ( or almost none ) flicker is there anymore. Also you could add images that need to be loaded to your first pages, thus...preloading them.

I stumbled on several solutions for it when working on the above mentioned sample. I dont think that approach is a solution for your specific issues. If you add a sample with a few pages of the course at hand, i gladly add/test some preload solution on it.

Kind regards,

Math

Tanks Math, this could be a way to hide the problem, but it still exists (see attachment, 2 seconds waiting before images are loaded; the learners perhaps don't see that they have to wait, but they are still waiting (total page takes 7 seconds for me)).

Our pages are loaded in 0.5 or 0.6 seconds, thats not bad. I don't want to add more code to hide a problem making the learner wait longer for the complete page to load. But we will have a look, if your idea could help us.

At the end, it would be more interesting to find a way to load images before the trivatis*.js scripts are stopping browser actions for 300-400 ms (in our environment) and have the images right there, wenn the scripts want to use them.

Yes, like I said above, Lectora pages are fundamentally different from most HTML pages. In most pages, IMG elements are already part of HTML. So the loading order is roughly like this:

- load HTML

- render HTML, including IMG elements

- load source files for IMG elements ---undefined show pictures

In other words, scripts before images.

I am not sure why Lectora does not include IMG elements into HTML at publish (as it does with text elements) and creates them on run-time. There is probably a reason for this.

Yeah, see your concern. That sample is just that...a sample, no optimization. A lot of the assets and libraries inthere could be removed for sure. One thing you could do offcourse...use preload.js or jquery lazyloader ( http://jquery.eisbehr.de/lazy/ ) to preload assets before the trivantis*.js scripts kick in. If needed edit those scripts so they have the code for preloading in it...

The thing is, the image elements are created by the scripts. So first HTML loads, then JS scripts load, then they execute and create IMG elements, then the browser loads the source images into the elements. Even if you cache all the images and make them available to the browser, you will have to wait for all JS to execute. In the screenshot below, it will take loading from 580ms down to 420ms. On slower connections, you will see a more substantial effect, because loading of images will be the biggest issue. However, I don't think you can push it below 300-400ms anyway and that is enough for flicker effect to appear.

The tricks mentioned here will certainly help but as long as Lectora courses are multi-page, it will be like this. On the other hand, the whole internet flickers, try moving between Wikipedia pages for example, so maybe not such a big deal for learners as we the developers tend to think :)

As you mentioned Wikipedia: I tried a search for "Knorpelfisch" (hoped to find some images in the article) and voila, images are loaded before (some) js (see attachment). This is managed by serverside PHP and of course Wikipedia pages are different from Lectora modules...

One option may be to eleminate js code, which is not needed (if there is such code) - but not by hand...

Anyway, thanks for your interest and if we find a solution, we will post it :-)

In the "render HTML" step above, its just the inline portions of the HTML which are rendered, which is just the text. Text is inline in order to be "searchable" by search engines.

The other objects are loaded after the scripts because it is the scripts that contain all of the formatting information for the images. This is especially true in the era of responsive design where things are moving, sizing, and even disappearing based on device rotation.

We definitely hear you though, and are working towards a new publish architecture that will alleviate the "Flashing" issue that gets referenced quite a lot here on the forums. It really comes down to multi-page/single page publishing, if there is another page to load, someone with a slow connection will always see a flash no matter how optimized the page load is.

Hi John,

Maybe an option is... for the single page publishing approach.

Give exactly that as an option to the user when publishing... a checkbox... singlepage...

If he checks it...the title will not be published as 40 different pages, but as 1 page with 40 sections down..so being scrollable... or to even go a step further...give the user the choice of several layouts... in rows and colums of sections... a max of 5 down, and then to the right.... something like that...

Maybe this sketch clarifies it...

I added a One-Page-Setup approach to illustrate what i ment with the above comment.

If from a normally created .awt with multiple pages, the published content could be outputted like in this sample...

http://community.trivantis.com/shared-content/one-page-setup/

Well that would solve the white flashes, giving the option to preload/prefetch assets and create gorgeous transitions.

Let me know what you all think...

Kind regards ,

Math