If you scroll down to the bottom you’ll see they have a list of links which, when you hover over them, activate full screen videos and images. How do they do this? I can replicate the design easy enough but I don’t understand how they can get the page to load so fast.
They are lazy loading them : https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video/
They have everything well compressed as well.
If you have a slow connection you can see smaller versions (very pixelated) load first while the real full size versions load in the background before being swapped out without the visitor normally noticing.
This happens from top to bottom, so the page will display as soon as the first content is loaded and the lower content is loaded by the time you scroll down to it.
@doobox What I thought. So the next questions is - why can’t we get this inbuilt to stacks or RW? I know @tav has this as an option in Limelight and @joeworkman has it in Moving Box. If lazy loading works this well it should be the default for images and video surely?
There are tradeoffs. One of which is the need to know the image size in advance. To provide a tiny pixelated image to display first while the full image loads, the tiny image needs to be resized with code to the actual size of the full size image, to prevent breaking the layout. We are unable to get the size of the full size image with code until it loads (catch 22). And in the case of an RW developer, we can’t know in advance what size images will be used.
Thanks @doobox So, if I’m understanding this properly, then it needs to be incorporated into RW by Realmac.
Not quite. It would need to be a Stacks API addition. A way for the developer to grab the physical size of an image provided in the stack before that image is loaded into the DOM.
So for example, the user add an 2000px x 1000px image to my stack.
I can’t know what that size is until that image has loaded (I’m beat already).
But if I knew the size of that image in advance, I could…
Create a tiny copy of that image (this feature already exists in the Stacks API)
Then put the tiny copy where the real image should be and resize it to the size of the real image should be, thus filling the space, just very pixelated.
We can detect when the real image actually loads, so at that moment we’d swap out the tiny version for the real one.
I used to have a stack called Caffine, that did this. But it made a lot of guesses (under the circumstances), so wasn’t perfect.
1 Like
maybe. we generally put all the API changes in a free update like v2.5, v3.5, v4.5 etc. and stick to user-centric changes for the big paid upgrades.
but this is only a rule of thumb. sometimes a low risk API change is a good thing. this one is on our list to try. if i run into challenges building it, i’ll push it out too v4.5.
but speaking of versions and strategy…
i’ve been brainstorming on ways to increase the frequency of these update cycles.
one paid upgrade every three years is not the best business model.
i think users would rather have a $10 upgrade every year rather than one $30 upgrade every third year. more frequent features is really just a good thing. spreading out the painful $$$ part isn’t bad either.
some features of stacks 4 have been done for year! it’s so painful holding on to those things while the other features finish!!!
5 Likes
This is an often overlooked design that everyone who creates web pages with images should be aware of and try to address. The issue is often seen at it’s worst on a mobile when a site loads and as images become visible the whole site gets pushed down with every image which can make a web page unusable until the whole page loads…
There a few things that can be done to reduce or fix the issue.
The most important IMHO, is to use background images for large images at the top of a web page (or sometimes called banner images back in the day) as this is the most critical image to load quickly. All worth using for any other image which go full screen width.
E.g. Using a BG image in SectionsPro set to a % or height, width or fixed height, defines the height of the image space required for the image to load up. Obviously warehousing that image will help on the next load of that page or if that image is used on other pages. Another way to set the size of a BG image is to create a tiny transparent PNG image with the aspect ratio that you want for the main image. E.g create a 16px wide by 9px high transparent image if your main large image has a 16:9 ratio and just drag that small image into SectionsPro as content, and set SP to use the height of the content. Stacks will grow that image width to the screen width size and the height will become the correct height. The image will create the right space while the BG image is loaded in the background.
Also, if you can, use a good Image stack and the one that comes to my mind is the Foundation Image stack - a clever well thought out stack. It not only has a Pre Load Image option where you define the width and height of the image, but you can also use the Load Mobile Image First option and add a suitably sized mobile image image that will load and grow to the correct aspect ration for devices bigger than mobile.
@aidy I have the fastest connection available available in Thailand. This is what I see for the first 15 seconds. It’s actually more frustrating than useful.
@Isaiah I, personally, would greet more regular updates due to the fact that, as a volunteer worker, I have very limited financial resources. As you noted $10 ‘hurts’ less than $30.
@Webdeersign I too like the Foundation Image stack features, I just wish that the ‘Mobile First’ function were ‘When Mobile Detected’.
The jump between the mobile optimised image (often with a different crop) and the desktop image can also be quite disturbing.
Agreed but it can be better used in the example above as a valuable work around. I gave up using the mobile image long ago your very reason.
@isaiah I would much rather $10 per year, rather than $30. For me it has nothing to do with finances. I’d simply rather get cool new stuff sooner rather than later.
… the only possible problem I potentially see with the $10/year model is you’d then have to provide support for folks with even a greater array of version numbers. But as long as that wouldn’t be a huge additional problem for you I see no reason not to go with more frequent updates.
4 Likes
Yearly updates @isaiah has my vote. Like @mitchellm said it’s not financial, It getting the improvements faster that’s important.
Being that Stacks is an essential tool for almost all RW users (does anyone use RW without stacks?) why is the wealth generated by the two essential tools so unevenly split?
One can’t exist without the other, but the wealth is split something like 80/20. Makes no sense and is a very poor model.
One word of caution on lazyloaded images. It needs to be implemented correctly or none of your images will be indexed by Google.
Yes yearly please :-)
I’ve also seen some issues with compatibility with other JavaScript stuff. Not saying you shouldn’t use it just make sure you test everything with it
That site takes 27 seconds to load on my 7mbs broadband connection - not very fast at all!
Speed is really relative.
An awful lot of website designers and developers seem to forget that not everyone has real high speed like Gigabit connections. In The U.S. it’s estimated that 1/3 of the population doesn’t even have high-speed internet at home. They may be using public WiFI, Mobile plains with data caps or other means to connect like the workplace.
I have a cabin in the high country with a lot of homes around me where there’s a “waiting list” to get a 1.5mbs DSL. The only “broadband” you can have there is one mobile company ( Verizon) you can get a connection at the best speed of about 1.8mbps. My only other choice would be a Satellite internet, very expensive and data caps.
1 Like
Agree with Rob on this. My connection speed is usually around 1 to 2 mbps (on a good day) and this was a frustrating site to visit. All blurred images after 20 secs.