Support » Plugin: Site Kit by Google » Site Kit and Site Speed

  • Resolved wafwaf

    (@wafwaf)


    Hi,

    When we do a speed test on GTmetrix, our YSlow Score is D (66%) and we get a “C” (76) score on the “Leverage browser caching”. The errors appear to be coming from Site Kit (Google manager, Google Syndication, Google tag services, Google Analytics).

    When we deactivate the Site Kit plugin, and redo the test, our YSlow Score goes up to C (74 %) and the “Leverage browser caching” score goes up to “B” (80).

    We love your plugin! We hate to keep it deactivated, but also, we hate to have our site slowed down because of the errors. Can you please fix it?

    Thank you and stay safe.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Support James Osborne

    (@jamesosborne)

    @wafwaf The resources you mentioned are loaded to make use the different Google services. Whether you implement the different Google services manually or using Site Kit they are required in order to connect your site.

    If you temporarily disconnect the available modules within Site Kit you’ll notice there is minimal impact on your site, with Site Kit placing only a meta generator tag in your sites source code.

    For any tracking services or to connect to, whether it’s Google Analytics or other vendors scripts will be added to your site, meaning you’ll likely encounter the same notices when using any site measurement tools such as PageSpeed Insights or Web.dev.

    Hopefully that answers your query, let me know if you have other question in relation to this.

    Hi James,

    Thank you for your prompt reply. What you described is true. I like to point out the slight difference in Leverage Browser Caching:

    With Site Kit: Leverage Browser Cashing is C (76)
    Without Site Kit: Leverage Browser Cashing is B (80)

    It may not be a significant improvement, but it’s an improvement.

    Do you suppose a wonderful brilliant programmer at Google can help bring it up to B? (An ‘A’ score will be amazing, but I’ll settle for a ‘B’ score 🙂

    Have a great day.

    • This reply was modified 2 months, 1 week ago by wafwaf.
    Plugin Support James Osborne

    (@jamesosborne)

    @wafwaf Certainly an additional 4 points in your score is an improvement. There are a few ways to make the most of browser caching, including WordPress plugins or changes to your hosting or .htaccess file. You’ll find a guide on browser caching from the same report where you performed a speed test.

    Thanks for opening a support topic, I’ll be sure to pass on your message to the programmers! Have a great day also.

    @wafwaf I’ll chime in here, since I found your post whilst looking for something else. I suspect what you’ll find is that the browser caching issue is occurring because Google is not setting cache expire headers on the assets that are getting pulled from their domain. Or, if those headers are being set, they don’t have a long enough time-frame on them to be of much use (according to the YSlow and PageSpeed, via the GT Metrix tool you’re testing your site with).

    I say this, because I’ve seen this issue with pretty much anything my WP sites pulls from Google. The more assets pulling from Google servers, the worse the “browser caching” rating will get on GTMetrix (due to cache expire HTTP header not be set on those assets).

    As far as I know, the only way around that problem is to take as many of those assets as you can (where possible) onto your local server. For instance, hosting Google Fonts locally, and hosting GA script locally, etc. For example, here’s a plug-in that allows you to host GA locally without much fuss: https://wordpress.org/plugins/host-analyticsjs-local/. What this means is the GA javascript will be delivered to the user from your server, not from Googles. Same thing with Google fonts is easy to achieve. I suspect same thing with GTM is easy also.

    However, if you are using Site Kit, I suspect hosting those scripts, etc., locally isn’t going to be so easy, as SK is designed to pull them from Google servers only.

    It would be nice if Google developers actually set browser cache expire / cache-control headers on the assets in the first place. Perhaps there’s some technical reason why they think it’s not a good idea? I can’t think of one. It’s been an issue for many years.

    • This reply was modified 2 months, 1 week ago by inspired888.

    @jamesosborne
    As per my reply to the OP…
    I suspect the issue is that he can’t control the cache expire headers on assets coming from Google servers. Google would need to implement that on their servers. I suspect it is the lack of those HTTP headers on assets from Google servers that is driving down his page speed score.

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.