I preload the stylesheet like this.
<link rel="preload" href="public/style.css" as="style" onload="this.rel='stylesheet'">
Since preload is not supported in all browser, I add follwing at end of body
<link rel="stylesheet" href="public/style.css>
This will load the stylesheet twice. Is there a way to do it better? That is, without making the browser re-parse the stylesheet?
Make sure to unchecked the disable cache while testing in the chrome dev tool. Otherwise, it will not use already preloaded cached links.
With disabled cache:
Without disabled cache:
Related
I'm trying to preload an SVG logo on my blog, but Chrome keeps giving me a bunch of warnings and I don't seem to be able to fix them.
Logo: https://keestalkstech.com/wp-content/uploads/2019/05/ktt-logo.svg
Preload link: <link rel="preload" href="https://keestalkstech.com/wp-content/uploads/2019/05/ktt-logo.svg" as="image" type="image/svg+xml" crossorigin="anonymous" />
I'm getting the following warnings in Chrome:
A preload for 'https://keestalkstech.com/wp-content/uploads/2019/05/ktt-logo.svg' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.
And:
The resource https://keestalkstech.com/wp-content/uploads/2019/05/ktt-logo.svg was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally.
Any pointers?
Looks like removing the crossorigin attributes fixes it:
<link rel="preload"
href="https://keestalkstech.com/wp-content/uploads/2019/05/ktt-logo.svg"
as="image"
type="image/svg+xml" />
I tried below and works well. Not sure though if it is the best way to do it
fetch('svg-path').then(() => {
// do load it into your dom using any library you use
// and it should load without flickering
})
So far works well for me.
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 page that embeds another page, let’s call it frame.html:
<iframe src="sub-page.html">
On sub-page.html, it loads some CSS and an image:
<link rel="stylesheet" href="sub-page.css">
<img src="sub-page.svg" alt="Sub-Page">
I at first thought that I could speed up the loading of these sub-subresources by adding <link rel=preload> to frame.html:
<link rel="preload" href="sub-page.css" as="style">
<link rel="preload" href="sub-page.svg" as="image">
…but that doesn’t seem to help, looking at the resulting waterfall graphs.
The specs for preload links seem to emphasize that it’s only for subresources of the current page, but since you can preload font files that are called from a stylesheet, it’s plausible that resources of a frame could also count. Am I missing something, like the correct use of the crossorigin attribute?
Yes.
Turns out I was looking at an old, unpurged version of the page when I was trying my performance tests.
<link rel=preload> absolutely can preload subresources of an <iframe>’d page..
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...
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.