Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas from Responsive-lazy #150

Closed
Maximilianos opened this issue Aug 24, 2015 · 2 comments
Closed

Ideas from Responsive-lazy #150

Maximilianos opened this issue Aug 24, 2015 · 2 comments

Comments

@Maximilianos
Copy link

Does this: https://github.com/ivopetkov/responsively-lazy#a-new-concept sound valid to you?
and if yes, does lazysizes support using a srcset as well as a data-srcset?

@aFarkas
Copy link
Owner

aFarkas commented Aug 25, 2015

Does this: https://github.com/ivopetkov/responsively-lazy#a-new-concept sound valid to you?

Yes.

if yes, does lazysizes support using a srcset as well as a data-srcset?

Yes. In general lazysizes is extendable. So you can transform anything into anything. Luckily this pattern isn't so special (in terms of transformation) and it works out of the box see also here: https://github.com/aFarkas/lazysizes/tree/master#modern-transparent-srcset-pattern

And in case this is the only lazyload pattern you use, you can disable lazySizes in non-supporting browsers:

window.lazySizesConfig = window.lazySizesConfig || {};
lazySizesConfig.init = ('srcset' in new Image());

As you see I already put this pattern into my documentation. Also it has a small variation: the fallback candidate should also be added as first candidate in the data-srcset attribute. This is due to a bug in iOS8, which was fixed in iOS9 (iOS8 always takes the first candidate from data-srcset. The above script has not this problem, because it handles srcset different.). In case the markup isn't provided this way, this can be easily achieved with JS in the lazybeforeunveil event. (see below.)

In general (and this will take some time):
While the script itself has some issues, the markup pattern/idea is pretty brilliant. Still, I put this pattern as last example (I might move it up with time as soon as browser supports gets better).

In general this pattern is used to trick bots especially the google bot to fetch a good src.

Some notes to the other patterns he mentions: LQIP and noscript. The author says that these are used to workaround this problem. But the LQIP pattern produces an additional request, hence has performance problems and the noscript pattern is verbose.

Actually the LQIP was not introduced to solve the SEO/bot problem. It originated here as a true performance pattern, not a SEO workaround. So the additional request is intended performance-wise. The true argument against LQIP, that is raised sometimes is: A fast but bad impression with a switch to a good quality might be disturbing for the user. So whether you choose this pattern or not is about this psychologic effect in your special case. A big improvement that deals with this psychologic effect is the blur up/fade in technique.

The noscript pattern was invented for users, which disable JS for whatever reason and also not for google. In fact google doesn't read noscript content so much, because this content is often used for SEO spam. While this use case isn't so important nowadays, the fact that the pattern above doesn't solve this problem reveals, that it also produces "broken" markup, but it is so tricky that current bots doesn't fail here. But there is no guarantee for the future.

Back to the pattern.

The main contra point is: current browser support.

If you use lazyload as a nice to have, you can already use this pattern as a progressive enhancement strategy. But in case you have a lot of images and lazyloading is crucial for your users, you simply can't. Obviously with changing browser support for srcset this evaluation will change.

The main pro point: current bot support

But I have to constrain this a little bit, because lazysizes is also special in this case.
In case google is important for you and you are using lazySizes you won't have any problems, no matter what markup pattern you are using. The reason is google bot is executing JS and lazySizes takes precaution to show google all lazyload content before onload happens. This comes out of the box.

Read later tools/apps normally already work if there is not only a data-srcset, but also a data-src attribute (like this pattern provides).

And all social network bots and other search engine bots, can be supported with open graph or microdata/shema.


And here is the JS to move the fallback image candidate forward:

(function(){
    'use strict';
    var regW = /(\s*\d+w)/;
    var img = document.createElement('img');

    if(('srcset' in img) && !('sizes' in img)){
        document.addEventListener('lazybeforeunveil', function(e){
            var elem = e.target;
            var srcset = elem.getAttribute(lazySizesConfig.srcsetAttr);
            var src = elem.getAttribute('data-iossrc') || elem.getAttribute(lazySizesConfig.srcAttr);

            if(src && srcset && (index = srcset.indexOf(src)) > 0 && (srcset.split(src)[1] || '').match(regW)){
                elem.setAttribute(lazySizesConfig.srcsetAttr, src + RegExp.$1 +', '+ srcset);
            }
        });
    }
})();

I hope this answers your question.

@Maximilianos
Copy link
Author

It does. I appreciate the time you spent on this answer, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants