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.
Related
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>
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...
So I recently started playing around with Amazon S3 and build a small sample web app. I followed the tutorials and my site, including images, are working correctly. I added a favicon.ico file to my root directory and referenced this in my index.html but no matter what I do I cannot get the favicon to display in a browser search bar, tab, or favorites list.
Note that I used the Bucket Policy permissions provided by the tutorial in Step 2.1 - Part 4 to make my objects publicly accessible, and I can also navigate to the link provided by the S3 Bucket that holds my favicon.ico object and I can see it in the browser, so I know the link works.
If the link works, everything in the Bucket is publicly accessible, and the rest of my site works including images, what am I doing wrong?
File Structure
index.html
...
<!-- Favicon -->
<link rel="icon" href="favicon.ico" type="image/x-icon">
...
Amazon S3 Bucket
Bucket Policy
UPDATE: I have also tried removing <link rel="icon" href="favicon.ico" type="image/x-icon"> completely from my index.html and also modifying it to have a / in front of favicon.ico like so <link rel="icon" href="/favicon.ico" type="image/x-icon"> to no avail.
I was able to get this to work by using the full exact URL of the favicon in the s3 bucket.
<link
rel="shortcut icon"
type="image/icon"
href="https://my-s3-bucket.s3.us-east-2.amazonaws.com/favicon.ico"
>
Cloudfront has permissions to access this file, it just has to know where it is- no public bucket required.
If you just do the relative path, i.e. href="favicon.ico", that will resolve to your-www.domain.com/favicon.ico, which is not where the file actually is.
If you're using some kind of bundler, a relative path may work as long as you specify the base path as the url of the s3 bucket.
It sounds like this is not an Aws/S3 issue. You can check this by opening the website locally (i.e. from local disk rather than S3) and seeing if the favicon appears. Note that Chrome won't display favicons from locally hosted sites though.
Here a few things to try:
Clear you browser cache and reload the page
Run the website locally and open it with FireFox
Try and use a png favicon instead, in case
there is a problem with your x-icon
From my experience, there is no need to add anything in bucket policy.
Once you added your production build resources to S3 > Then give full public access to all your files. Hit next and save. Remember you are giving read-only access to the public. Please find the screenshot.
Make sure you check the metadata from favicon like below
Check the permission whether the group you are trying to access have both read and write permissions.
Hope it helps
I ran into the same problem and was curious why one of my pages worked and another did not.
I found that if I set this in the HTML (inside the tags in the header, all worked well:
<meta>
<link rel="shortcut icon" type="image/icon" href="images/favicon.png">
</meta>
I also tested with this, and it also worked:
<link rel="shortcut icon" type="image/icon" href="favicon.ico">
Apparently, if it is not specified, it will try to pull it from amazon.com.
Note: In my case, the main bucket is public, however I also put in a bucket policy which restricts the access to a specific CIDR block.
Hope this helps!
I got the same issue, I updated the content type of my favicon to image/vnd.microsoft.icon
and problem resolved.
Also after changing the content you should open you tab in a new incognito window or do empty cache hard reload.
I had the same issue today. I can confirm that it's some caching issue of Google Chrome. At first I had it like:
<link rel="icon" type="image/x-icon" href="/favicon.ico" />
And it didn't work when loaded for AWS as well as when I tried loading directly from file system. So it should be:
<link rel="icon" type="image/x-icon" href="favicon.ico" />
as confirmed by loading from file system. But it still didn't work in Chrome. I also tried all sorts of things before I found the issue on reddit where author said it resolved itself so I decided that should be some caching issue so I tried opening my site in MS Edge and it worked. So I closed all Chrome related processes (including secure shell extension started one) and restarted Chrome and it worked. I bet it's caused by some sort of "web pages loading optimization" feature which caches (more aggressively) meta data parts of your page or something like that.
I am a little bit late, but in case somebody had this issue, in my case, I had to add behavior to CloudFront with path pattern /favicon.ico that would point to my s3 bucket, and that would fix it for me.
How would one employ SRI for resources included by a .css file included over a CDN.
For example, if you include this in your HTML:
<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous">
This will load fonts included via the CSS, such as url('../fonts/fontawesome-webfont.woff2?v=4.7.0') Of course, these fonts could be tampered with, to take advantage of some untold browser exploit, so it makes sense to force hash checking in them, too.
How can one tell a browser to perform the SRI-hash of the fontawesome-webfont.* files that are loaded via the .css?
Note: It looks like sub-sub-resource hashes are not yet supported, though I'm not sure if that's the latest.
As far as I'm aware, subresources of resources that have a valid integrity and CORS header shouldn't need anything more. At least, that seems to be the case with CSP enforced on Opera.
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.