https://fonts.googleapis.com/***
 

The various versions of this link used within XC5, will always cause issues with leverage browser caching / static - mainly because, being provided by Google 8O yep, there's no caching allowed. This has been briefly touched on before, but in a different forum query that was specifically related to the Google Analytics Module. This last item in this post (from that thread) is the most relevant : https://forum.x-cart.com/showpost.php?p=402988&postcount=7

It's actually specified within 6 different XC5 Core files (2 x php / 1 x twig / 3 x html) in our own, current XC5 based store, but we're pretty sure that NONE of these, other than the two shown below possibly, have any association with the module above. FWIW, If we run our Dev Store with that module disabled, this font is stalled called up. Your own store(s) may be different...
So our two questions are:

Are there any specific, technical reasons WHY this font still being used? e.g. No Google based module. like the already mentioned Google Analytics Module will work properly without the Core inclusion of this font... or something like this?

If so, has anybody actually, genuinely tried this at XC?

On a different domain / non-XC5 setup that we have, we removed all links to Google's "...you can't cache our precious content, otherwise we'll take our ball home..." and replaced them with alternative settings, with no detrimental effect, but it's not XC5, so this discovery may not be relevant here....

In most of the current XC 5 Core code, it's presented this way:

So to summarise, if there's NO absolute technical reason for still using it, could it be replaced with an alternative (cacheable) font with effect from XC 5.3.3.* onwards? Because XC5.* is getting better and better (XC 5.3.2.9 is like chalk and cheese compared to XC 5.1.* :mrgreen: ) so it seems a big limiting factor, to be forever following Google's own, convenient 'rules'.

Re: https://fonts.googleapis.com/***
 

I believe it is not the case for Google Fonts, only Google Analytics is affected.

I've checked the online demo and it loads Google Fonts from the browser cache on subsequent views.

Re: https://fonts.googleapis.com/***
 

With the arrangement of the wording, we're not totally sure what this answer means. Sorry! :oops: Did you mean:

a) The ONLY thing that DOES use those Google Fonts is the Google Analytics Module? Therefore removal of that specific Module will (or should...) also remove those fonts from the XC5 Core because they are not needed anywhere else?

or

b) Those fonts are actively used in several areas within XC5 and the Google Analytics Module is just one of them?

If it's a) then back to the question in the previous post: If it's b) then it's the same question really for all Google based modules supplied by XC (not any third party) as the coding is generated in-house. Yes they have to be to Google's "rules' but #FontFailure may not be an 'offence' that subsequently causes Module failure. As per our own previous example, but also accepting that it was NOT within XC, so it maybe different when it's tried by the XC Dev Team

Re: https://fonts.googleapis.com/***
 

I mean that the "Google don't cache their resources" issue applies to Google Analytics scripts only.
Google Fonts resources are cached by browsers.

Re: https://fonts.googleapis.com/***
 

Just re-run prior to this post:

Yes, that makes perfect sense - see above and there's some corrective actions on this module due in XC 5.3.3.* anyway we now understand. Thank you.
Hmmm but here is the problem. They are NOT cached in the same way as anything else 8O so all the previous questions still apply, aka WHY are the used? For what specific technical reasons? etc & What 'alternative' tests have been done, if everyone can see the sense in replacing them :D/

Re: https://fonts.googleapis.com/***
 

I doubt there were any technical reasons to use Google Fonts. Designers use web fonts not because it is a technical requirement :-)

As for caching: I don't get what the problem is. Google do cache their fonts in the way that allows them quickly fix problems with their CSS (if any happens).
Their FAQs state that font files are cached for a year. Yes, they send an HTTP header that makes their CSS files to expire in a day, but these files are so small that this should not noticeable affect the page loading time. Plus it will be loaded once a day only.

What problem do you want to fix by switching from Google Fonts to "alternatives"? What alternatives would you suggest?

Re: https://fonts.googleapis.com/***
 

Exactly. So why did they choose Google, when there are many alternatives available, all, without the "joys" of dealing with Google. That's the question in a more specific format really. See other posts on Google's "self-focus first" etc 8O The most relevant part here is "...that allows them..." That's the issue isn't it? i.e. Them not XC or any end-user or whoever else. See comment above ^ :D/ That's the question that the Dev Team / Designers should be asking themselves surely? This particular issue is well known and well recognised (examples have already been posted by us and others on here and in other forums etc) so from a pro-active perspective... the answer, to what appears to be a self-created problem lies with Dev Team / Designers. As end-users, we can only report factual issues with finished XC products. If we become deeply involved in XC core design or re-design, we've lost focus on our own business we think :D/ We only use Unix / Apple products and their third-party compatible products ourselves, but if there is an issue with any of these, it gets fixed. Quickly. Especially if it's a publicly acknowledged issue.It does not matter at all what we suggest. It's 100% the designer's choice. If he/she/they did not see this issue in advance, okay everyone is human and it's a minor issue compared to others if we are being honest. However, many alternatives are readily available to them. If a designer opts for the "....ohhhhh....don't know which to choose..." approach. It would then becomes a bigger issue!

If it can be fixed. Fine. If it can't or it won't (because it's not sufficiently important enough currently) that's also fine. All actions are by the Dev Team though, not end-users who have identified the issue. Let's see what happens as we move into XC5.3.3.* etc

Re: https://fonts.googleapis.com/***
 

I'm sorry, but I don't see what problem you want to fix there by switching to a different font provider (besides you don't like Google).
Browsers cache Google's font files (for a year), and cache the "wrapping" CSS file for a day - this is pretty enough for fast site loading.
It may be a good idea to cache some static files forever, but in case of fonts supplied by any third-party provider it is good to have the fonts updated with newer versions released by the supplier.

Re: https://fonts.googleapis.com/***
 

No problem. Let's agree to disagree :mrgreen: We did say "it's a minor issue compared to others if we are being honest" For various factual reasons to be fair. Those that do, simply don't know, what they don't know when it comes to Google 8OYes to all of this. However, it's not caching per se. It's the 'leverage browser caching' that's the issue we're referring too. Have a look in Stack Overflow or Mobile First Design or anywhere similar. There's no 100% achievable / manageable solution IF Google Fonts are used. The real irony is that this will show as an issue on Google's own PageSpeed Tests and the relevant section within PageSpeed Tools. :wink: Meanwhile, if other fonts are chosen... well :D/

Re: https://fonts.googleapis.com/***
 

You can self host them you know... https://google-webfonts-helper.herokuapp.com/fonts

Shameless plug, little experiment (in SEO mainly). Search for 'Google Fonts List' in Google :-D