always fall back to native browser lazy loading

[steve8708]

this helps ensure best possible perf scores

[mrkoreye]

Two things:

1. Should we add some logic to determine if loading is present in the browser and then have that bypass our built in lazy loading behavior so we don't end up negating the built in browser lazy loading? https://web.dev/browser-level-image-lazy-loading/#how-do-i-handle-browsers-that-don't-yet-support-lazy-loading
2. Ideally we don't lazy load images above the fold, so should we include logic here to only add this attribute to ones we actually want to lazy load?

[steve8708]

my thoughts on these were

1. I lean against for a first test, bc our lazy loading has nice fade in animations and in theory if the browser sees it's above the fold it'll load in immediately anyway
2. I leaned against this too bc our pre computed above/below fold detection isn't as accurate as a users browsers for their exact device size, and so google page speed will ding that for some specific device you should have lazy loaded an image. plus the browser should see that image is already in view and load immediately if it is anyway

a large impetus here is

1. places like shopstyle who have lazy loading off, and are dinged for it but this one attr will fix that
2. times that our above/below fold lazy flagging isn't exactly accurate for the specific device
3. easy migration path - e.g. just start using this now and later we can turn off our JS if this works well
4. support older browser and new ones pretty seamlessly without additional code/logic

basically, if my assumption is right that the browser will identify correctly when an image is or isn't in view - the only net affect here is any time our lazy loading is wrong the image will pop in. any time its' right ppl still get the nice fade animation. and over time if the browser native is better and more supported we'll just turn our lazy off for everything and let the browser do it's thing

[mrkoreye]

I like that reasoning. Works for me 👍