Has anyone tried successfully to reduce loading times of Typekit by using preload or prefetch? i.e.
<link rel='preload' href='...' as='font'>
<!-- and/or -->
<link rel='prefetch' href='...'>
Is it a practical or possible in the current Typekit loading setup?
You could try preloading Typekit's script:
<link rel="preload" href="https://use.typekit.net/[YOUR_KIT_ID].js" as="script">
I've tested this and it does seem to work. The 'loading order' of waterfall changes — the Typekit script moved up to tie second with my main (deferred) javascript file. As for performance, I'm not seeing much improvement — if any at all.
As of today, link rel='preload' is not implemented by any browser.
I have tried using link rel='prefetch', and Chrome did prefetch that font, however, it ignored the prefetched font and downloaded it again when it needed it.
Related
Various tools (Google Lighthouse, PageSpeed, etc.) suggest preloading key requests via <link rel=preload> to increase web site performance. For static files whose filename is known and does not change everything is clear. However, how can I specify a versioned file (https://www.example.org/primeicons.e12e3d4e5dfc6a78e9ee.ttf) with changing filenames in the link with the preload hint? In my specific case, it is the PrimeIcons font from PrimeNG.
In the absence of working alternatives, I finally changed the value of the outputHashing attribute from all to bundles in the angular.json file, and additionally included <link rel="preload" href="primeicons.ttf" as="font" type="font/ttf" crossorigin> in the <head> section of index.html.
For the assets, which are served without hash now, this may cause a cache issue after re-deploys in production, but I can personally accept that.
I have a website https://www.budowle.pl/ which I want to optimize and increase its score in Google Page Speed Insight.
One of the problems I have is:
Preload key requests
1.68 pp
Consider using `<link rel = preload>` to prioritize fetching resources that are currently requested later in page load. Learn more.
URL
Potential Savings
/fonts/icons.ttf?myrw8(www.budowle.pl)
https://developers.google.com/speed/pagespeed/insights/?hl=en&url=https%3A%2F%2Fwww.budowle.pl&tab=mobile
I haven't found a way to deal with it :(
In the code I have (according to me :)) the correct tag:
<link rel="preload" href="https://www.budowle.pl/fonts/icons.woff?myrw8" as="font" type="font/woff" crossorigin>
I also tried, without this parameter ?myrw8, but without success.
If anyone has any idea what I could do, I'd appreciate your help.
Kind regards, Wojtek
Well the problem is that you are looking at the wrong file :-P
You have done everything correctly for the "icons.woff" but you haven't done rel="preload" for the "icons.ttf" file.
This appears to be referenced in your main.css file.
Now as woff font format has very good support you may decide to remove the reference to the ttf format (which would probably be my recommendation as the browsers that don't support woff don't support ttf anyway except very old android devices (less than version 4.4)), if not just add a preload for the ttf file in the same way.
<link rel="preload" href="https://www.budowle.pl/fonts/icons.ttf?myrw8" as="font" type="font/ttf" crossorigin>
This is my example code:
<body>
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" />
<style>
#font-face {
font-family: "Roboto";
src: url("/fonts/Roboto-Regular.woff2") format("woff2");
}
* {
font-family: "Roboto", sans-serif;
}
</style>
<section>
<h2>Hello World</h2>
</section>
</body>
What I expect:
Roboto-Regular.woff2 gets downloaded once. The second access should take <5ms since it's reading from cache.
What I actually see:
Roboto-Regular.woff2 gets fully downloaded twice. The second access took as much time as the first one.
The blue bar here is Content Download.
What I have tried:
The solution suggested here: preloaded images get loaded again. But I quickly realised my issue has nothing to do with cache. I have configured serverside cache-control, as seen here in the response header for the file:
The previous waterfall screenshot is taken after a hard refresh (ctrl F5); this one is taken after a soft refresh:
This time both requests simply got their response from cache, which shows that cache has nothing to do with the whole situation.
So what has gone wrong here?
My environment:
Windows 10 Pro N 1909
Google Chrome 78.0.3904.108 x64
It turns out it's related to CORS.
I accidentally stumbled across the answer today when I noticed several new warnings in the console that weren't there before.
These warnings basically described my issue exactly as they are. I did a quick Google search and landed here: Preloading content with rel="preload", which said:
One interesting case where this applies, even if the fetch is not cross-origin, is font files. Because of various reasons, these have to be fetched using anonymous mode CORS.
As suggested, I simply threw in crossorigin to my preload declaration:
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" crossorigin />
And my preload worked.
Also
If you are preloading a resource with MIME type of fetch such as .json, you also need to include the crossorigin attribute in your preload declaration for similar reasons (I assume) (Reference).
For the next one who arrives here:
If you have the same issue (double download of your asset) but you've already set the crossorigin property.
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" crossorigin />
Are you really requesting an asset cross-origin?
Try removing it!
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" />
When opening the developer tools, chrome disables the cache, what can cause a reload of resources. Remove the checkmark on the disable cache box in the menu bar mostly fix the issue.
I have a generic css file with all fonts the website is using (local).
Inside i have for example :
#font-face {
font-family: "LemonMilk";
src: url("../fonts/LemonMilk.otf");
}
.....
.LemonMilk{
font-family: "LemonMilk" ;
font-size: 4vh;
}
I have many many of them, but some pages need only few of them, but still i load the whole file for every page :
<head>
....
<link rel="stylesheet" href="../css/style.css"/>
Problem:
Most of my pages will delay loading them and show system fonts for a second or 2.
Tried:
<link rel="preload" as="font" href="/style/some.otf" type="font/otf" crossorigin="anonymous">
which provide a warning message that they where loaded but never used within a few seconds of page loading. But i do use them right away.
Questions:
How to reduce delay?
If i include a css with all fonts, will he load also the ones i dont use?
why preload didn't work ?
when using #font-face in CSS, it is down to browser, how it behaves.
It's good to use external CSS sheet for declaring fonts.
If this doesn't help, you could try making different CSS files with fonts for different subpages. As you mentioned, you don't use all fonts on all subpages, so it may reduce the filesize and consequently load faster.
Once I was working on a project with a lot of fonts and I had similar problem. The best solution then was to base64 encode all of the fonts I used. So by that approach, all of the fonts had to be loaded before HTML was parsed and displayed. Font squirrel's webfont generator found here: https://www.fontsquirrel.com/tools/webfont-generator can be really helpful tool. If you will use it you should click "Expert" and "base64 encode".
Also, for testing and seeing how your load times improve, you can check out Fontloader here: https://github.com/smnh/FontLoader . It detects when fonts of the specified font-families loaded and rendered by the browser so you can see which step is taking the most time.
As I have enabled the HTTP2 protocol of IIS, but the requests of the main javascript files were still queueing. According to the explanation of queueing by Chrome, I really don't know what cause this.
You can check at here: https://app.youjustgo.com/zh/
Queueing:
HTTP/2 means that more assets can be downloaded at once - not that they will be.
Browsers have various heuristics as to what to download and when.
For example, if an image is needed by a CSS file, then that image cannot be requested until the CSS file is downloaded and processed for example (ignoring preload). So in this case the CSS and the image will not download in parallel despite HTTP/2 allowing this.
Another issues is that <script> tags can change the content of the page, so unless it is explicitly marked as async (or defer) it is "render blocking". This means any JavaScript further down the page will not be run until the <script> tag is run. Now a browser could scan ahead and download the future scripts and just not run them until it needs to, if it wants, with the slight risk that it's a wasted download if the scripts subsequently are not actually needed. That's up to the browser and maybe Chrome decides it's not worth while to do this.
Looking at your specific site, your home page looks to be made up of basically only script tags. You could investigate the use of async or defer to allow more downloads to happen in parallel, but if you want the real performance improvement, you probably should go back to the basics of coding HTML, with CSS, and then enhancing it with JavaScript, rather than coding it all with JavaScript.
I'm also not sure of what the point of your preloading of your CSS is?
<link rel='preload' href='https://api.tiles.mapbox.com/mapbox-gl-js/v0.37.0/mapbox-gl.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel='preload' href='https://api.mapbox.com/mapbox-gl-js/plugins/mapbox-gl-directions/v3.0.2/mapbox-gl-directions.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="https://npmcdn.com/angular2-toaster#2.0.0/toaster.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick-theme.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
Preload is intended for assets that are not immediately apparent to the browser (like the image example above) to allow it to start downloading earlier. Here you are using it to preload CSS. The only advantage is it will not be render blocking and then you use the onload function to display it. However CSS normally is render blocking for a reason - otherwise your content looks unstyled. And because it is preloaded it's requested as high priority (which the CSS would have been requested as anyway), so not sure what advantage this is giving you to be honest. Very confused...