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:
Page Stats
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.
Optimization Suggestions
Enable compression
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).
Eliminate render-blocking JavaScript and CSS in above-the-fold content
Your page has 1 blocking script resources. This causes a delay in rendering your page. None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML. Remove render-blocking JavaScript :
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?
Prioritize visible content
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.
Minify JavaScript
Minify JavaScript for the following resources to reduce their size by 2.9KiB (32% reduction).
-
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/…unpkg/react-dom-factories@1.0.2/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.
Minify HTML Compacting HTML code, including any inline JavaScript and CSS contained in it, can save many bytes of data and speed up download and parse times. Minify HTML for the following resources to reduce their size by 1,019B (20% reduction).
-
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.
