: Enabling compression for font loaded via googleapi I'm using Google Fonts (https://www.google.com/fonts) to add special fonts to a website. I chose to include the font via a link in the head:
I'm using Google Fonts (https://www.google.com/fonts) to add special fonts to a website.
I chose to include the font via a link in the head:
<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:400,700,300" rel="stylesheet" type="text/css">
When I check my Website with Google's PageSpeed Insights, it tells me to optimize the comprssion
How can I improve the compression, as it is a google server, or is it Google who has to enable compression for this?
Note:
Apart from the link-variant, I could also use
@import url(https://fonts.googleapis.com/css?family=Roboto+Condensed:400,700,300);
or
<script type="text/javascript">
WebFontConfig = {
google: { families: [ 'Roboto+Condensed:400,700,300:latin' ] }
};
(function() {
var wf = document.createElement('script');
wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})(); </script>
But these do not change anything regarding the compression.
The javascript-variant could possibly even slow the rendering of the page?
I checked the documentation, but it did not help developers.google.com/fonts/docs/technical_considerations
More posts by @Caterina187
1 Comments
Sorted by latest first Latest Oldest Best
This is an issue with the test, not with anything you are supposedly doing wrong. From your screen-shot I can see that the potential size savings is only 526 bytes which is well within the size of a single network packet (an MTU, about 1500 bytes) which makes it unlikely that compression of that last wee bit of data will help.
At best, you would eliminate a single packet. You should ignore that part of the test result and move on to more important things like image optimization which can yield far bigger gains. There are other flaws in speed testing methodology such as Pingdom's deducting points for not sending a 'Vary: Accept-Encoding header' for sites delivered by SPDY (an older HTTPS protocol which made that header completely unnecessary) so I just ignored it. The tests aren't perfect.
If you still feel that optimizing for this test is important then consider downloading and hosting the fonts yourself. You should know that this is perfectly legal under the terms of that particular font license and you should also know that WOFF and WOFF2 fonts (which are all you ever need to serve for modern browsers) are by default a compressed file format. Saying 'compressed WOFF font file' is redundant, it's like saying 'compressed gzip file'.
And if you do decide to self-host the fonts grab them from Brick web fonts instead, these are slightly larger but much better looking fonts that weren't optimized to death. It's worth it if you care about how the fonts look on high DPI displays. Here are the links to the fonts from your question, for example:
brick.a.ssl.fastly.net/fonts/robotocondensed/300.woff
brick.a.ssl.fastly.net/fonts/robotocondensed/400.woff
brick.a.ssl.fastly.net/fonts/robotocondensed/700.woff
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.