Google says my homepage get’s 65/100 and says it is slower than average. I know the ‘Subscribers box’ is an issue to page speed, and as requested I have posted a separate question about this, but it also says there are other issues with my page. Like the server should be using Gzip compression etc, I have listed the individual suggestions Google makes below…
Can these individual things listed be fixed either by me if I have set them up wrongly, or by WIX if they are problems with the site builder itself to help page speed?
It seems that website usability plays an important part in where sites rank in Google’s results, speed obviously plays a part in that, not only if Google doesn’t think your site is friendly because it’s slow to load but because if users leave because it’s slow that hurts too.
Google’s PageSpeed Tools Say:
Statistics show that the median page on the internet requires 4 render-blocking round trips and ~89 resources (1.3MB) to load. But this page appears to use more resources. PSI estimates this page requires 5 render-blocking round trips and 175 resources (2.6MB) to load. Fewer round trips and bytes results in faster pages.
Compressing resources with gzip or deflate can reduce the number of bytes sent over the network. Enable compression for the following resources to reduce their transfer size by 356.8KiB (72% reduction).
- Compressing https://static.xx.fbcdn.net/…rc.php/v3iEpO4/y6/l/en_US/s8WClR75CD2.js could save 356.8KiB (72% reduction).
This skimlinks code above is needed on my homepage, I loaded it myself, but did I load it in the wrong place perhaps, and that’s causing Google’s issue?? I tried originally to put it in the Tracking & Anaylitics Tool but Skimlinks didnt seem to be able to read it that way?
Your page requires additional network round trips to render the above-the-fold content. For best performance, reduce the amount of HTML needed to render above-the-fold content. The entire HTML response was not sufficient to render the above-the-fold content. This usually indicates that additional resources, loaded after HTML parsing, were required to render above-the-fold content. Prioritize visible content that is needed for rendering above-the-fold by including it directly in the HTML response.
- None of the final above-the-fold content could be rendered even with the full HTML response.
Minifying https://static.parastorage.com/…statics/viewerComponentService.bundle.js could save 1.4KiB (38% reduction) after compression.
Minifying https://static.parastorage.com/…@1.0.604/dist/statics/dataRefs.bundle.js could save 652B (41% reduction) after compression.
Minifying https://static.parastorage.com/…firstname.lastname@example.org/index.js could save 548B (33% reduction) after compression.
Minifying https://static.parastorage.com/…c/minified/plugins/ScrollToPlugin.min.js could save 230B (16% reduction) after compression.
Minifying https://ding.wix.com/asdk/dispatcher.js could save 131B (15% reduction) after compression.
Minifying https://www.save-money-now.co.uk/…hboard-statics/1.102.0/asdk/handler.html could save 747B (30% reduction) after compression.
Minifying https://gs.wixapps.net/…=Europe%2FLondon&viewMode=site&width=564 could save 272B (11% reduction) after compression.