[Support request] Idea: Implement CSS’ New “content-visibility” for Dramatic Performance Boost

Home Forums Support [Support request] Idea: Implement CSS’ New “content-visibility” for Dramatic Performance Boost

Home Forums Support Idea: Implement CSS’ New “content-visibility” for Dramatic Performance Boost

  • This topic has 18 replies, 3 voices, and was last updated 5 months, 3 weeks ago by 93487u5tr938ouh4trnos8fyoh.
Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
  • #1424754


    According to this article, there is a new CSS property,which is “content-visibility” that dramatically boost the rendering performance.

    content-visibility: the new CSS property that boosts your rendering performance:

    The web.dev portal is operated by Google and is aimed at Chromium related browsers and the web in general.

    With the recent change of Microsoft serving an Edge browser that uses the Chromium engine, I think the market share of the already dominant Chromium browsers family is growing even more.

    It is important to mention that the crawling and rendering of the web content from the biggest search engine – Google is also happening with a the Googlebot running on a headless evergreen Chromium.

    With the already release Web Core Vitals that would become a ranking factor, performance is getting even more important than before.


    As GeneratePress always strive for performance excellence, I think implementing the content-visibility CSS property would dramatically boost the SEO and UX for the users.

    Someone already mentioned that in the Facebook group and described that after a developer implement it, the performance boost was very solid, yet the implementation was not that hard.

    https://web.dev/measure/ – This is web based Google Lighthouse performance test.

    https://developers.google.com/speed/pagespeed/insights/ – Google PageSpeed Insights

    As an internet marketer I urge you to implement this thing.

    Thanks very much in advance!

    Customer Support

    Hi there,

    yes, the CSS Containment spec is pretty exciting stuff. It is something we are keeping a close eye.


    If the words of the FB group user was that implementing it is just few lines of code for the theme, could we expect this to ship soon?

    Customer Support

    Main concern:
    Chrome has implemented what is still a draft specification CSS property. Firefox have deemed it ‘prototype worthy’, and other browsers are yet to implement this. This leads to an overarching concern that implementing Chrome specific CSS today ‘may’ create future issues if other browsers adopt the specification in a different way.

    Implementation concerns:
    Where exactly the required CSS is placed will vary from one layout to another.

    For archives it could be applied to each individual post element. This would probably work quite effectively. But would require testing when ajax, infinite scrolling or masonry is in place.

    Other layouts – not so easy. Applying content-visibility to a single post or page container would probably provide no benefit as on intial load, part of that container is generally visible ( unless the user has a Full Screen hero above the post content ). Instead you would want to pass the property to elements within the content – that leads to the question as to whether this should be passed to Blocks rather then theme templates.

    So there are a lot of things that need consideration and testing to implement what may only be a few lines of CSS. Of course there is nothing stopping users from applying the CSS themselves at this time.



    Now that Chromium basically powers everything, from the most used mobile phone OS default browser to the most used desktop OS default browser, why not consider utilising this?

    View post on imgur.com

    Customer Support

    65+ % of browsers already use it. With the ongoing purchase of new PCs and Chromebooks due to the pandemic, you’ll get two OS both using Chromium.

    About the performance, from an SEO stand point, there are three variables and I’ve already seen some people utilizing this for their sites and the performance gain was pretty significant when measured for Core Web Vitals.

    I’ve got a confirmation today that in the next update a competitor of yours on the same principle for a performance based theme would incorporate it. Maybe when/if they do it I can share the results here?

    The other part I couldn’t understand since I don’t code. I was thinking this is some sort of a native lazy load similar to what they have for images and JS, no?

    Customer Support

    For sure, you can share any info you find here – it would be much appreciated.

    The technology is browser side and is part of the CSS Containment Module Level 2, which is browser side code and uses similar principles as the native lazy loading.

    More info on the Module here:

    Note: it includes some ‘use with caution’ comments, which is something anyone implementing this needs to be aware of. Also note comments on the intersectionObserver API, which is what native lazy loading uses and may other scroll scripts ( such as animations, masonry layouts etc ). So developers would need to be aware of how there other scripts are affected by this CSS.


    OK, giving you my SEO perspective on this.

    This would be the theme of 2021.

    https://web.dev/vitals/ – Core Web Vitals

    These are part of the Page Experience ranking factor which will start in 2021. These Core Web Vitals would be measured from field data, not lab data.

    That basically means that users and Googlebot [which is also running headless Chrome] would benefit from using that technology the same way people benefit from native lazy load of images and iFrames.

    What is the critical difference between that and the lab data is that when you have 65% as of now of the device owners and keeping rising of it, having Chromium based browsers running, that would significantly help the marketing in the search engines for these site owners.

    Some people do use GTmetrix with the Lighthouse API but it gives them an inflated number due to the fact that GTmetrix are using powerful VMs with fast internet connection which is significantly better than the field data that most would have.

    Long story short, the metrics that people brag about with the GTmetrix screenshots are far from perfect as they are not real. The PageSpeed Insights tests are somehow more close to the reality, despite still being lab data and thus – inflating the numbers.

    You may already saw it starting, but everyone would ask for speed in 2021. It would be the topic of the year, trust me on that. So everyone would look how to improve their speed, their real speed, measured throw the field data for these three speed variables that are reported in the G Search Console and G Analytics.

    For years I’ve seen people basically playing the numbers, inflating their scores on the lab tests with tricks. That won’t play a role anymore.

    So the demand for speed would be great and this is the opportunity to shine, GeneratePress is already a fast theme, but there is a room for improvement, by utilising this, you could gain competitive advantage and from a marketing standpoint you could sell the theme on the angle of performance which as said would be the topic of 2021.

    Expect many people to come to GeneratePress for performance in 2021.

    Having one more extra exclusive part before the competition would play a significant role as a competitive edge over the competition if you find a way to implement it properly.

    If people notice uptick in traffic and rankings after switching the theme, which is far greater than anything before, the snowball effect would follow.


    This is exactly what I am talking about:

    “Gutenberg’s Faster Performance Is Eroding Page Builders’ Dominance”

    “After recreating the same design with Gutenberg and GenerateBlocks, Van Deusen saw a small difference in GTMetrix scores.

    He found the most profound difference when testing with Google’s PageSpeed Insights, where Elementor scored 46% on mobile, and 83% on desktop.
    “Because I’ve had such poor luck getting any kind of decent scores with Elementor sites (especially on mobile), I’ve given up using this tool,” Van Deusen said. “Not because it’s not a valuable metric (in fact, it may be the most valuable since this is how Google sees things), but because there wasn’t much I could do about it.”

    In contrast, the page built with Gutenberg gave him a 94% score on mobile and a 99% on desktop.

    “In terms of performance, straight out of the box; Gutenberg absolutely smokes Elementor,” Van Deusen said. “However, each time I’ve taken Gutenberg for a spin, I’ve left frustrated. As soon as I feel like I’m getting the hang of it, eventually the wheels come off and I’m back to installing Elementor.

    “But when your PageSpeed Insights scores go from 46% to 94%, it’s time to perk up and pay attention.”


    Check out the article. 2021 is the year of performance and people would look for the PageSpeed scores which are closer to the field data that G would use than the useless GTMetrix which runs the Ligthouse API on superior VMs with fast internet connection. You have the chance to knock out the competition with a competitive edge.

    I seriously know what I am talking about, I live and bread among these people. The #1 topic is performance and when the G update hits and use the Core Web Vitals in May 2021 the demand for speed would be incredible. You have the historical chance to get an extreme amount of people jumping on the GeneratePress train by doing something more exclusive than anyone else.

    I would lie if I say I didn’t pitch the same to other high performance themes. So, I am honest.

    Btw the majority of PageSpeed benchmarks above 90+ would actually be considered middle rank speed scores in the field data.

    What I am trying to say is that there is an invisible gap in performance that not many people realize and sharing this is somehow a sacred knowledge that I hope you use to gain that extra comparative edge.


    This is a really interesting discussion, and I’m wondering if have been further thoughts from the GeneratePress team over the past few months?

    Performance is for sure the watchword of 2021, with Google’s CWV hitting next month…

    In addition to archive pages, I’m thinking these elements could also be good candidates for “content-visibility” optimization:


    Would this be possible/easy to implement myself with GP hooks or similar?


    Customer Support

    Hi there,

    As its just a CSS property:


    you can write you own CSS rules for what elements you want to apply it to – for example; applying it to the Comments Area:

    .comments-area {
        content-visibility: auto;

    OK, great – thanks David!

    New to this but I did some more reading and according to this article shared above, another CSS selector along the lines of contain-intrinsic-size: 1px 1000px; might be needed in there as well.

    I also discovered that some WP optimization plugins are starting to add this as a “lazy render” feature.

    Customer Support

    Thats correct – if you’re applying to elements that have an unknown dimension and you want to maintain scroll bar sizing then intrinsic sizing is required – most applicable where you have sections in the middle of your content that are not of a defined size….
    The major benefits come from elements such as Images where a network request is required.

    Glad to be of help.


    Thank you David! Major benefits from images, but I’m guessing it still helps performance when the browser doesn’t have to render content that’s off-screen.

    So perhaps something along the lines of:

    #nav-below {
    	content-visibility: auto;
    	contain-intrinsic-size: 1px 1000px;

    [ Per https://css-tricks.com/more-on-content-visibility/ ]

    What do you think would be the best way for simple archive pages, for each individual post element?

    Have you all tested anything like this to see how it works, or if there are any issues?

    Thanks again!

Viewing 15 posts - 1 through 15 (of 19 total)
  • You must be logged in to reply to this topic.