Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#49 2021-02-28 10:34:07

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,541
Website GitHub Twitter

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

#50 2021-02-28 11:40:57

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,679
GitHub

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

#51 2021-03-01 00:51:55

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,493
Website

Re: Core Web Vitals to affect Google rankings May 2021

philwareham wrote #329073:

I’m using the content-visibility declaration 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 ?

Offline

#52 2021-03-01 08:27:37

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,541
Website GitHub Twitter

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 with loading: 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

#53 2021-03-02 13:21:32

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,753
Website

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

#54 2021-03-06 08:46:47

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,538
Website GitHub

Re: Core Web Vitals to affect Google rankings May 2021

phiw13 wrote #329080:

The broader point / benefit of the content-visibility property 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

Offline

#55 2021-07-06 17:33:22

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,679
GitHub

Re: Core Web Vitals to affect Google rankings May 2021

Offline

#56 2021-07-06 19:01:56

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,178
Website

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

#57 2021-07-07 02:25:27

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,493
Website

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 ?

Offline

#58 2021-07-07 19:36:46

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 8,753
Website GitHub Twitter

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.org | hblack.net | State Machines | NeMe @ github
I do my best editing after I click on the submit button.

Offline

Board footer

Powered by FluxBB