0

I've done a lot of optimization and when I test my page I get different results all day long and different results just minutes apart.

Same page tested just minutes apart gives a variance between 94 > 61 (big variance) and anything in between. Server NOT under load nor are any of errors to do with that either.

One test will give me a CLS of 0.007 and 1 minute later the same test on the same page will give a CLS of .714 and sometimes 1.4 for the same page?

Secondly I have a live and staging site I get scores of 10+ on everything from the staging site versus the live site. They are mirrors of each other and everything is identical same web server, same config, same shared mariadb server, same php everything is the same.

Additionally today results from the staging site were much higher because no unused js or css errors were being thrown despite it being identical, both sites have all the same js all the same css. This is a reason the staging scores higher. Also nothing to do with cacheing either as I even disabled the CDN and WP Rocket on the staging site and it STILL scored higher than the live site.

I'm stumped.

2021-04-22 update 07h05 Morning tests give me a CLS of 0.005 for mobile and 0.002 for desktop. Repeat test 2 minutes later gives me 0.841 for mobile and 0.002 for desktop. I really need to try and understand why such a variance on the layout shift, I will eventually figure I out.

2021-04-23 I had mentioned I was getting a consistently higher score between my staging and live site. Today I figured out why. I have Bunny CDN disabled on my staging site, the moment I enabled it CLS gets worse and score drops. I didn't imagine this either, I turned the CDN on and off several times and immediately scores rise / drop. I then set the CDN to be reserved only for images and then its fine, the moment I allow the CDN to cache js & css the scores flop and CLS returns. How is this even possible?

MitchellK
  • 2,322
  • 1
  • 16
  • 25
  • 2
    I’m voting to close this question because it is a rant with no direction or question involved. – GrahamTheDev Apr 19 '21 at 17:54
  • 2
    If you want to rephrase the question with some specific points I am happy to help you identify the cause of your CLS. Variations like that are often down to some items loading early on one run and late on another run (network variability). If you want to share a public URL for the site I am happy to have a look for you. Also if you give me a second I will drop you a couple of answers I have given previously that may help you identify the issue. **Above all realise the Page Speed Insights is not where Google gets their data** - they use the CrUX dataset which is from real browsers. – GrahamTheDev Apr 19 '21 at 17:57
  • Not directly answering your questions but [here I explain how CLS is measured "in the real world" until **page unload**](https://stackoverflow.com/a/67075241/2702894), [this answer and comments may be useful for getting the CrUX data](https://stackoverflow.com/a/63468582/2702894), [second half of this answer tells you about using the Web Vitals library to gather real world information from your site](https://stackoverflow.com/a/65689435/2702894). – GrahamTheDev Apr 19 '21 at 18:03
  • Hopefully those will help you a little with understanding, [and this readme explains variability](https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md) – GrahamTheDev Apr 19 '21 at 18:03
  • 1
    Drop your URL in the comments, I will find the problem for you as I have yet to see the tool misreport CLS. – GrahamTheDev Apr 19 '21 at 18:09
  • Hi @GrahamRitchie thanks a lot you can look at https://livingcanvas.co.za/shop/ much appreciated its driving me mad – MitchellK Apr 21 '21 at 07:16
  • I have rephrased my question @GrahamRitchie – MitchellK Apr 21 '21 at 07:17
  • 1
    Close vote retracted, I understand the frustration but your question is a lot easier to follow when you "take the anger out" as someone once put it to me Will have a look for you later. – GrahamTheDev Apr 21 '21 at 07:27
  • 1
    Is it on desktop, mobile or both? I can see an issue on desktop where you haven't inlined all of your critical CSS so you get a huge shift when "floatsome.css" loads in (it is your image boxes at the top which jump into position). Haven't seen it on mobile yet. Do you know how to run a performance trace as layout shifts show up there now in Google Chrome and that is the easiest way for you to post them. Finally - remove whatever nonsense is stopping right click and F12 from working - they offer no protection but cause accessibility issues (and make debugging harder!). – GrahamTheDev Apr 21 '21 at 10:22
  • Sorry one sentence got mangled there due to writing it on phone, it should read "Do you know how to run a performance trace as layout shifts show up there now in Google Chrome and that is the easiest way for you to **find** them.") – GrahamTheDev Apr 21 '21 at 11:59
  • Hi Graham thanks I will have to relook at this. I have WP rocket doing minification could that be causing the inlining? I don't have CSS combine anywhere because of http/2 which was not recommended. I need to learn how to do a proper performance trace, dev tools is a complex beast. Can you give me easy steps to do that? Thanks for your time. Will disable right click for now I do it purely to keep the majority of users from downloading images but didn't consider it could be causing problems as well. – MitchellK Apr 21 '21 at 14:23
  • Morning @GrahamRitchie I am trying to diagnose a layout shit happening on my main logo on mobile but just cannot get the chrome experience section to show (90.0.4430.85) according to Insights this is the only shift I have left on mobile but I cannot figure out whats causing the shift even though I can see it when I refresh a page on my phone. – MitchellK Apr 23 '21 at 07:28
  • This is really driving me nuts @GrahamRitchie latest Chrome on both Arch Linux and macOs neither one can run lighthouse on the page in mobile mode. The macbook is stuck at about 90% through the test and it's been like that now for 45 minutes and is just causing CPU at 100% - on Linux same thing full of errors – MitchellK Apr 24 '21 at 08:23

2 Answers2

1

The same thing happens to me. If you have a type of DOS limiting enabled on your server then this may be the cause. Google is being redirected to the cache because of the repeated visit, hence the extra time because of the redirect.

awholegnuworld
  • 381
  • 1
  • 12
  • 1
    Ahhh I never thought about that. I do have an anti DDOS system in my nginx blocker I will have a look in the logs tomorrow. Weird thing is both the staging and live sites have the same config but definitely worth checking logs tomorrow to make sure. – MitchellK Apr 19 '21 at 16:00
  • Another thought is that google may limit how many queries you can do per minute before it goes to their cache. – awholegnuworld Apr 19 '21 at 16:02
  • 1
    I thought all their tests would be cache busting? Otherwise how do you even know if the changes you made are any good. Hmm let me leave and test again tomorrow. Will update here. – MitchellK Apr 19 '21 at 16:19
  • 1
    If your redirect to cache is taking enough time to affect your PSI score *negatively* (as it should be faster not slower to serve from cache / CDN) then you don't have the cache configured correctly. The whole point of the cache is to reduce time not increase it. Also PSI is always run from a cold cache at their end (first time visitor) so no chance of any interference from their end. If PSI manages to trigger DDOS protection I would be amazed as it just requests the page via a headless web browser, so unless you ran PSI from 50 different tabs at once I doubt DDOS is getting in the way. – GrahamTheDev Apr 19 '21 at 18:06
  • I checked server logs and it's not my blocker doing anything and each test done is also 100% direct to my server so no cacheing issues or anything – MitchellK Apr 21 '21 at 07:30
0

I have resolved all CLS issues with inlining my theme CSS and some other fixes. Now consistently 0 CLS across desktop and mobile and score of 97 mobile and 100 desktop.

MitchellK
  • 2,322
  • 1
  • 16
  • 25