Huge difference between mobile and desktop
-
So for some odd reason my mobile test speed is horrendous.
Examples
GTmetrix desktop: https://i.imgur.com/KFMGojk.jpg
Gtmetrix mobile: https://i.imgur.com/DjNIRHl.jpgGoogle desktop (74/100): https://i.imgur.com/YPvECD5.jpg
Google mobile (11/100!!!): https://i.imgur.com/uzTwSRR.jpgAny idea why this happens? Thanks
-
main thing are the render-blocking resources, as those have a huge impact on the start render/ contentful paint time. have a look at “inline & defer CSS”, there’s more info on that topic in the AO FAQ.
hope this helps,
frankwhat you are you seeing it related to what I brought up here:
https://www.ads-software.com/support/topic/autoptimize-not-differing-css-when-critical-path-present/
So if you are using this plugin there will be nothing you can do in regards to this mainly because of the way the generated minified css is being enqued in the top rather than the bottom area because of the “deferring” technique not being recognized by google page speed test.
Hopefully frank will add this option of choosing to place it in the footer in a future release very soon.
So if you are using this plugin there will be nothing you can do in regards to this
That is not correct @jiggaman ; the render-blocking CSS can be fixed by using inline & defer and can have a huge impact on start-render time and thus on the pagespeed score.
moreover; on my own site I do also have the “opportunity” listed, but I do have a perfect pagespeed score (not that that really matters, see below), so “defer unused CSS” does not have to cause a drop on pagespeed score;
and as I wrote on your own thread;
the pagespeed score as such is not used as a ranking factor, with Google instead using more objective KPI’s such as time to first byte, time to start render (significant/ contentful paint), time to onload, time to interactive.
and regarding
Hopefully frank will add this option of choosing to place it in the footer in a future release very soon.
Afraid this won’t be in an AO release really soon. I might add some experimental stuff to the AO CCSS power-up though, so feel free to install that and keep an eye out on what happens there?
frank
the render-blocking CSS can be fixed by using inline & defer and can have a huge impact on start-render time and thus on the pagespeed score.
Perhaps there is where the confusion is on this issue that you are not seeing in your test scenario what I and some other people that are reporting things are all seeing. To clarify I do have that option checked, and I do have the “above the fold” css in that box and loading properly.
However, google still gives, one, and only one opportunity for fixing for higher score: Defer unused CSS.
Expanding that options reveals #1:
https://mydomain.com/wp-content/cache/autoptimize/11/css/autoptimize_2eaa76bf85cb120c345075454917f0a7.css
#2 it is wanting to differ the loading of:
fonts.googleapis.comThe code for the autoptimized css file is:
<link rel="preload" as="style" media="all" href="https://mydomain.com/wp-content/cache/autoptimize/11/css/autoptimize_fb40d31806e9b4e97767cd6f9bd9f580.css" onload="this.onload=null;this.rel='stylesheet'" /><noscript id="aonoscrcss"><link type="text/css" media="all" href="https://mydomain.com/wp-content/cache/autoptimize/11/css/autoptimize_fb40d31806e9b4e97767cd6f9bd9f580.css" rel="stylesheet" /></noscript>
and it is on the same line of code as the above the fold css which is in the <head> block.
Additionally, for suggestion #2 this is in the head block.
<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'" id="ao_optimized_gfonts" href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800%7COpen+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800%7CRaleway%3A100%2C100italic%2C200%2C200italic%2C300%2C300italic%2Cregular%2Citalic%2C500%2C500italic%2C600%2C600italic%2C700%2C700italic%2C800%2C800italic%2C900%2C900italic%7CRaleway%3A100%2C100italic%2C200%2C200italic%2C300%2C300italic%2Cregular%2Citalic%2C500%2C500italic%2C600%2C600italic%2C700%2C700italic%2C800%2C800italic%2C900%2C900italic&subset=latin%2Clatin-ext%2Clatin%2Clatin-ext%2Clatin%2Clatin-ext%2Clatin%2Clatin-ext" />
Again, google page speed has no issue with this in desktop, only for mobile. Frank please let me know this is making sense. And if there is some workaround I am not getting please let me know. Thanks again.
Also in your demo page speed score…that site is extremely light in styling…i don’t think a blog like that is a common use case for most pages….so it might not trigger any of these issues we are discussing.
oh but the opportunity is listed, it just does not impact the score.
my 2c at the moment (but I might change my mind at any time) is that the main issue here is the sheer amount of unused CSS, so the root cause fix is making sure there is less unused CSS, I suppose by using something like plugin organizer to stop plugins from adding their CSS everywhere even if not needed.
Frank please let me know this is making sense.
I am very afraid that this whole GPSI update is not making sense (yet), no ??
And if there is some workaround I am not getting please let me know.
doing some experiments, but none yet. but it’s early days, after all ??
it seems as though google rolled their recent changes back, scores are back to where they were before the weekend?
I just checked now, and without any changes…my 63 score for mobile is now 95…so…i’m just gonna throw my hands up.
it seems as though google rolled their recent changes back, scores are back to where they were before the weekend?
Yes they do. Some of my optimized sites went back to previous figures. But not all of them.
us, feeble men (and women) can but bow our heads and pray for the GPSI-wrath not to come upon us (again) … :-/
- The topic ‘Huge difference between mobile and desktop’ is closed to new replies.