2

In Google Search Console > Core Web Vitals, I have many 'poor' pages, and the problem GSC is saying is Cumulative Layout Shift CLS.

Doing a page speeds insights (PSI) analysis, shows a very poor (26%) performance for mobile: 0.53

Looking at this helpful post on how to diagnose the problem (see where CLS is occurring), I find the largest layout shift as follows:

Block shifting but what is causing it to shift?

(This block - call it block A - was also shown in the PSI report). In mobile mode, the sidebar on the RHS sits above block A. So I thought that according to this post, the problem was the (adsense) ad causing the shift, so I placed a fixed-size (CSS) div block around the ad, but it seems to not have solved the shifting issue. I've also ensured all images have explicit sizes set (since they're using lazy loading too).

Any help would be greatly appreciated at this stage as it is causing a lot of frustration and impacting SEO performance.

(Edit): As for reducing unused JS, in chrome dev tools > Coverage, FB Connect and Google Adsense have huge amounts of unused JS code:

Unused JS code coverage

Also PageSpeed Insights is showing similar results: PSI unused JS

So goal would be to completely defer the loading of FB connect / twitter / Adsense JS code until page has loaded completely. https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript#how_do_you_load_third-party_script_efficiently

0
4

You've got a lot going on here that is contributing to your problems. At face value, it seems like you're spending an excessive amount of time on script evaluation.

enter image description here

This div is responsible for your layout shifting:

<div class="cell small-12 medium-8 large-9 small-order-2 medium-order-1 large-order-1 panel-content">


Ultimately, there is way too much going on to say definitively. I would start by the following:

  • Get rid of any render blocking assets - you've got 4-5 and I think they're all CSS.
  • Take advantage of resource hints such as preconnect or dns-prefetch to establish early connections to important third-party origins.
  • Figure out how to spend less time evaluating scripts, that's where the browser's main thread is spending a majority of its time.
  • Follow the optimization advice provided by PageSpeedInsights and make sure to do all of them.

I wrote an answer to a similar question you might find useful about determining the cause of CLS.

4
  • 1
    Thanks heaps Mike, appreciate it. Going to investigate these issues (lots to learn)
    – gvanto
    Dec 6 '21 at 8:39
  • I've replaced the 'async' with 'defer' on the above social JS includes, yet LightHouse (and PSI) is still complaining about unused JS ... if I understand correctly then deferring the JS to be loaded only once the document ready then it shouldn't impact initial loading time (even if a lot of the JS is unused, as shown by coverage)
    – gvanto
    Dec 9 '21 at 8:18
  • If you're properly dealing with javascript you should never see it blocking the browsers main thread. That goes for css as well. View the CPU utilization tab in webpagetest. If your users are in North America, UK, Russia, China, Australia, etc then make sure that you're not throttling with 3g, in reality it is rare in these places. Most users connect with at least 4g. Dec 10 '21 at 6:25
  • OK have added some tweaks. The most impactful ones were lazyloading as much as possible (including JS scripts themselves). Helpful links: uxdesign.cc/boost-page-speed-with-mindful-loading-28905edac84d (solution 2), digitalocean.com/community/tutorials/js-lazy-loading-scripts, stackoverflow.com/questions/69036877/… Merely defer-ing JS seems to not really help with PSI performance score, but lazyloading does
    – gvanto
    Dec 15 '21 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.