Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Core Web Vitals to affect Google rankings May 2021
I’m using the content-visibility declaration on parts of the Textpattern sites. Mostly to skip rendering the footer and a few other below the fold elements until near the viewport.
The decoding=async I’ve only used on a carousel – where I can’t lazy load the images for script reasons.
Offline
Re: Core Web Vitals to affect Google rankings May 2021
jakob wrote #328834:
I’m intrigued to read what the new AbookApart volume on Sustainable Web Design might have to say about that. Only when I ask to read a sample chapter, the site says okay but I never get the link…
I got as far as entering my email, being told it was on a “high bounce domain”, entering another one, getting confirmation, then being sent to a 404 page on getdrip.com. I’ll let you know if anything arrives!
Offline
Re: Core Web Vitals to affect Google rankings May 2021
philwareham wrote #329073:
I’m using the
content-visibilitydeclaration on parts of the Textpattern sites. […]
Thanks for the feedback. But what would be for images the hypothetical benefit of content-visibility: auto; in combination with loading: lazy ? I do see the point of decoding="async", in cases where lazy-loading is not possible, and the image is not especially important or “out-of-view” (e.g. your slide-show).
The broader point / benefit of the content-visibility property escapes me. there could eventually be a use case when the block contains dynamic content that consumes resources and that is “out-of-view”, e.g a automatic slideshow somewhere down the page. But otherwise? Plain static content that has already been downloaded and layouted won’t consume resources (battery life) anymore I would think.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Core Web Vitals to affect Google rankings May 2021
phiw13 wrote #329080:
Thanks for the feedback. But what would be for images the hypothetical benefit of
content-visibility: auto;in combination withloading: lazy?
I have no idea why that author has suggested using content-visibility: auto on images. It’s supposed to be for complex nodes of HTML that you feel the browser doesn’t need to process unless it comes into/near the view port – thus saving some CPU work on initial render. Since loading=lazy already does that for images I can’t see why you’d need content-visibility: auto too. Unless it’s to do with his blurry placeholder suggestion (which again I’d question because you can use loading=lazy to not load images until you have to anyway).
Offline
Re: Core Web Vitals to affect Google rankings May 2021
Not to put more work on your plates, but a concise write-up of all the optimizations you made for the family of sites and why you made them against motivations and compromises would make a nice Txp blog post.
Offline
Re: Core Web Vitals to affect Google rankings May 2021
phiw13 wrote #329080:
The broader point / benefit of the
content-visibilityproperty escapes me.
I haven’t read any literature on this but couldn’t content-visibility hypothetically not only load resources that are approaching scope but also unload them when passed the viewport?
While not to do with lazy loading per se – and doesn’t reduce the byte count – if used this way, it would have the potential to reduce the memory footprint on ‘infinite scroll’ blogroll type sites like tumblr and socmed feeds. Those sites can slow browsers considerably the further you get on in a feed as its memory uses expand to hold all the content.
Might content-visibility be able to help here by allowing authors to mark content up, and thus let the browser do virtual garbage collection, or at least do some clever “cursor” type behaviour (borrowing the term from relational database land) to only keep content in memory when it’s near the viewport? Scrolling back up wouldn’t re-download the assets, as they’d already be cached on disk locally, but it could just swap out the memory content to reduce load, conserve battery life and increase performance of looooong pages.
Like I say, no idea if this is in scope for content-visibility but it might be a consideration, now or longer term. That would explain its distinction from lazy loading, which is only concerned with fetching assets when needed while scrolling down a page.
Last edited by Bloke (2021-03-06 08:51:10)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Core Web Vitals to affect Google rankings May 2021
Tangentially related, and an interesting take:
We Increased our Lighthouse Score by 17 Points by Making Our Images Larger
Offline
Re: Core Web Vitals to affect Google rankings May 2021
gaekwad wrote #330896:
Tangentially related, and an interesting take:
We Increased our Lighthouse Score by 17 Points by Making Our Images Larger
An interesting situation as you say, but difficult to generalise to other situations (I’m not saying you are, but the title evokes that response). If I’ve understood it correctly, by making their images larger, they’re prioritising the attention that Lighthouse gives to their own images – which they can control the loading behaviour of – over those coming via Google Maps, which were previously causing the lower score. Kind of getting Lighthouse to “look over here not over there”. If browsers accord the same loading priority as the LCP stat in LightHouse, I guess users do benefit if the site’s own images show before the map builds. I probably don’t know enough about Largest Contentful Paint (or here) to have a qualified opinion but I can’t help thinking there must be other ways of prioritising the loading of own content over third-party sources to achieve the same benefit for users without necessarily sending users more data. Then again, the larger thumbs are nicer for users, so if there’s a perceived loading benefit, why not?
TXP Builders – finely-crafted code, design and txp
Offline
Re: Core Web Vitals to affect Google rankings May 2021
gaekwad wrote #330896:
Tangentially related, and an interesting take:
We Increased our Lighthouse Score by 17 Points by Making Our Images Larger
This looks like another of those “works for me” voodoo tricks to game Lighthouse (and thus G. search rankings). That said, in that case, larger images are definitively a plus for the user, in terms of information density, so that is a plus.
Chris Coyier at CSS tricks has quite a few times posted various tricks to let Lighthouse believe something or other is good, real real… most are in the voodoo realm as he admits between the lines.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Core Web Vitals to affect Google rankings May 2021
jakob wrote #330898:
An interesting situation as you say, but difficult to generalise to other situations (I’m not saying you are, but the title evokes that response). If I’ve understood it correctly, by making their images larger, they’re prioritising the attention that Lighthouse gives to their own images – which they can control the loading behaviour of – over those coming via Google Maps, which were previously causing the lower score. Kind of getting Lighthouse to “look over here not over there”. If browsers accord the same loading priority as the LCP stat in LightHouse, I guess users do benefit if the site’s own images show before the map builds. I probably don’t know enough about Largest Contentful Paint (or here) to have a qualified opinion but I can’t help thinking there must be other ways of prioritising the loading of own content over third-party sources to achieve the same benefit for users without necessarily sending users more data. Then again, the larger thumbs are nicer for users, so if there’s a perceived loading benefit, why not?
If GMaps were behind a cookie warning, as they should have been, Lighthouse would not be able to see them.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline