Font-awesome: Too many requests for older versions of Font Awesome

[hdodov]

Describe the bug
I created a new FA kit and put it in my site. However, when I look at the Network tab of DevTools (with cache disabled), I get bombarded with requests for font files. In my kit, I've set the version to "Latest" but I tried with a specific version too. I get the same results. Aside from slowing down the site, I think it's pointless. At least it could load the specified version first.

Test case
Fiddle. Inside, I've used my own icon kit. If you open DevTools with disabled cache and run the fiddle, you'll see that it loads all versions above 5.0.0 of the brands font.

The second screenshot is from the Network tab in the fiddle I linked. As you can see, it takes about 1.5 seconds to load all fonts and the actual icon appears when it loads the last one...

Expected behavior
FA should load just the font version I've specified.

Screenshots
This happens in my site:

This is a waterfall from the fiddle I linked:

Version and implementation
Version: 5.9.0
Browser and version: Chrome 75.0.3770.90 (Official Build) (64-bit)

• [ ] SVG with JS
• [X] Web Fonts with CSS
• [ ] SVG Sprites
• [ ] On the Desktop

Bug report checklist

• [X] I have filled out as much of the above information as I can
• [X] I have included a test case because my odds go _way_ up that the team can fix this when I do
• [X] I have searched for existing issues and to the best of my knowledge this is not a duplicate

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community and for reporting this.

I can confirm, there is definitely an issue with kits and webfonts

[nortonandreev]

I have reported this when the Kits have been released and still have not got any response. It is a major issue, as it makes loading the website and icons slower and also a website making too many request is a bad practice, so I will hold on from using the Kits until the issue is fixed.

[robmadole]

We'll be looking at kit performance for the free kits soon. @hdodov @nortonandreev can you confirm that HTTP/2 is being used? This should be the case but if not there could be some network-related stuff going on.

[tagliala]

@robmadole the protocol in the fiddle is h2

[hdodov]

@robmadole yep. I use the kit here. You can see for yourself.

[haideralipunjabi]

Facing the same issue with my kit. Has a huge effect on icon loading time

[bfiessinger]

Any updates on this? Can confirm the same issue, also using HTTP/2.

[nortonandreev]

Still not fixed in version 5.10.

[PropreCity]

I'm disappointed, it's a big waste of time for me because the kit was supposed to help me improve the loading time of my website and make FA automatically up to date. Hope this will be patched quickly.

[nortonandreev]

I'm disappointed, it's a big waste of time for me because the kit was supposed to help me improve the loading time of my website and make FA automatically up to date. Hope this will be patched quickly.

Yes, especially as they increased the price and also ditched the student pricing lol.

[Stick97]

Happening here too. We will not be using the kits until this is resolved as well. Does anybody know if this is this a problem with the Pro license as well?

[nortonandreev]

Any updates? It's been 3 months.

[Kearsan]

Still nothing about this issue? It's absolutely unusable in this state

[livthomas]

I've noticed the same problem when I updated my website to use the Kit.

What workaround do you use? I cannot find any documentation mentioning the FA CDN I used before.

[lumistu]

Happening here too. We will not be using the kits until this is resolved as well. Does anybody know if this is this a problem with the Pro license as well?

Can confirm it is still happening with the Pro license

[hdodov]

It's a bit alarming how such a serious issue is taken so lightly and hasn't been looked at for over 4 months. @lumistu that's what you call Premium Service, I guess.

[robmadole]

Alright, let me post an update here to address some of the issues. We are still working on two different fixes that will improve the performance of free (and Pro) kits using the "latest" version. We'll release these as soon as they are ready.

Regarding Pro kits, they only load the webfont files that they need in order to show an icon. @lumistu if you are seeing a different behavior please provide some details.

@hdodov we haven't posted an update but we have been working on Kits behind the scene since we've released them. We'll continue to work on them and make them better.

@livthomas the CDN is still available at https://fontawesome.com/account/cdn

[livthomas]

@robmadole Thanks. I've already switched back to the CDN since I modified my website to use AMP and the Kit doesn't work with it anyway.

I just want to say that I've encountered the problem with loading older versions of Font Awesome not only when using the latest version in Kit configuration but also when I specified an exact version. It still behaved the same way and loaded many older versions.

[Whateverinc]

I just noticed this too. Is this fixed?

[PhilETaylor]

@robmadole said

"Regarding Pro kits, they only load the webfont files that they need in order to show an icon. @lumistu if you are seeing a different behavior please provide some details."

I disagree.

Well I can confirm that Im loading a pro kit, but yet the page loads multiple old versions of fonts, both free and pro fonts, and is slow as hell. Exact same as the initial openers issues.

You can inspect this page https://manage.mysites.guru/en/login and see:
edit: had to move our site back to CDN, instead of Kits, just too slow with kits :(

[rimmeh8]

The funny thing is..... this is insanly bottlenecking the fonteawesome.com page too. It is loading an ridiculous amount of old webfont versions 👯‍♂ I stopped counting at 80 :D:D The Google Webfonts is going red when you add more than 3 to your Kit. And FA loads more than 80 OMG.

In my Opinion this trend to create Kits and tryinig to force people in cdn is the beginning of the end of every good Product.

[PhilETaylor]

yup - thats a perfect example of whats happening - live on fontawesome.com

[lumistu]

I suspect this is actually the intended behaviour - i.e. it is loading the version of the font when the icon was introduced for every icon you are using. It does have a noticeable perf impact - I had one of my devs switch from CDN to a kit without telling me thinking it was a quick performance win. I noticed the perf drop immediately and went looking for the source.

We've decided to build our own font from the font awesome svgs using a tool like icomoon.

[demyxco]

Like the others, I've switched back to the CDN version for my non-sage sites. Fortunately, Sage has the ability to "tree shake" specific svgs I need from FA.

[aidanlister]

This is crazy ... why is this a thing?

[aidanlister]

@robmadole this is not just happening for free kits - this is a paid kit and it's killing our site performance. We can't swap to the CDN version because we have too many subdomains.

[robmadole]

Alright. We're going to need some additional data to work on this. If you can share some HAR files with us that will be helpful. The performance problems that you all are running into don't match our testing locally so we've got something off. Some additional detail from real-world use cases would be super helpful.

Please send them to [email protected] to my attention if you can.

[marcelltoth]

I am running into this as well, and it renders Kits pretty much garbage.
@robmadole I will send you a HAR when I have the chance, but I don't see why you need it in the first place. As multiple people have mentioned above, there is a very simple repro case, right on your production site:

• Navigate to https://fontawesome.com/ in Chrome.
• Open up Dev Tools / Network.
• Hit CTRL-F5
• Watch

[robmadole]

_Alrighty, this is a novel so I'm trying to put the summary up top and what we plan to do about it._

Summary

• It's not loading older versions of FA, just the deltas between versions
• Kits are new. We aren't done with them. And we are trying something a bit innovative.
• Free kits in particular have poor performance (we've seen how much it sucks with our own eyes now)
• We already have a fix for "latest" versioned kits to improve caching
• We have a planned fix for the sequential loading of free kits
• Please don't send us HAR files of fontawesome.com-we need to see your projects ;)

---

Our next steps

Ok, Font Awesome, what y'all going to do about this?

1. Deploy our fix that improves kits using the "latest" version
2. Change free kits to work like the CDN (loading a single large file instead of smaller files)

---

Addressing each concern

Requests are for deltas between versions

@hdodov

FA should load just the font version I've specified.

The title of this issue is "Too many requests for older versions of Font Awesome".

It took me a while to understand what this meant but it finally clicked after a dozen or so of you mentioned it.

What it looks like in the network tab is that older versions of Font Awesome are loaded and then not used. Making the requests for these files unnecessary.

In reality, these files are deltas between versions. For example the fa-brands-400-free-5.0.0.woff2 contains 256 glyphs. The fa-brands-400-free-5.0.1.woff2 file contains 2. The next version: 3.

These represent just the icons that were added or changed in that version.

Cache behavior on first page load versus subsequent load

What I've seen repeatedly throughout this comment thread is a focus on the first page load time for Kits.

This is, of course, important but it's not the only measure of performance for a site. Subsequent page loads should take advantage of the cached assets and their performance profile will be different.

As we work on improving Kits we need to hear from the community about the overall performance of Kits. This means that developing with the Developer Tools open in Chrome or Firefox with "Disable Cache" checked is not indicative of user behavior.

This is not a excuse or a diversion off the first page load performance, you all have educated us on the wretched waterfall behavior and we have confirmed it locally. We get it: Kits has issues.

But as we make changes to improve kits we need to balance trade-offs and to do that effectively we need to model real-world use cases.

If you can share actual performance metrics from your projects that helps the most. And not data from fontawesome.com, from your sites you are trying to use Kits with. Sharing HAR files gives us a very detailed look at how you are trying (and failing because of perf issues) to use kits.

Using the "latest" version doesn't have optimal cache headers

@livthomas

I just want to say that I've encountered the problem with loading older versions of Font Awesome not only when using the latest version in Kit configuration but also when I specified an exact version. It still behaved the same way and loaded many older versions.

This is a confirmed issue. It was important in our first iteration of Kits to allow you to have an "ever-green" kit. When we released new versions of Font Awesome we wanted our customers to instantly get the benefits.

This had a trade-off: the cache headers (Cache-Control) has a short max-age. It causes lots of unnecessary requests to the server.

We have a fix for this that should be deployed soon.

Free version behaves differently than Pro

Our Pro version of kits that use webfonts also leverage the unicode-ranges property of the @font-face declaration in the CSS file.

The original purpose of this was to accomplish "automated subsetting". We knew with every version of FA that we released we were increasing the size sometimes hundreds of icons at a time. As of 5.11.0 our collection has over 7,000 icons.

We wanted Kits to help with the performance by only loading icons that were used on the page.

That's what unicode-ranges does. If you use only one icon from the fa-brands-400-free-5.0.2.woff2 file then only that file is loaded. From our experimentation this vastly improved the performance of webfont loading Font Awesome. But, this was experimental and we certainly want to hear from the community if you are seeing poor performance.

The free version of kits does not work this way (does not use unicode-ranges). We thought that separating these files but leveraging HTTP/2 multiplexing would result in roughly equivalent performance to simply loading everything in one large file. We were wrong.

Since Kits first implementation (this has been in the works for awhile) it appears that browser behavior has shifted.

What we see now if the horrible sequential "one-at-a-time" waterfall that @hdodov first posted when creating this issue.

Using HTTP/2

@nortonandreev

a website making too many request is a bad practice

We are leveraging HTTP/2 multiplexing so that this is not an issue. This works with our Pro kits but there is an issue with Free kits where this does not work correctly.

We will be addressing this in a future release of kits.

Pro kits having performance issues

@PhilETaylor

Well I can confirm that Im loading a pro kit, but yet the page loads multiple old versions of fonts, both free and pro fonts, and is slow as hell. Exact same as the initial openers issues.

As we've explained this is not loading multiple versions of FA but the delta between versions.

@PhilETaylor you said this is still slow as hell. Can you provide more details? We haven't been able to reproduce this issue ourselves (and if we can't reproduce it how can we fix it?)

Can you provide this:

• What kit you are using
• What browser you are seeing the behavior on
• Rough estimate of the number of icons you are trying to display
• Some idea of what "slow as hell is". Is it 1 second slower? 2 seconds?
• The HAR file so we can analyze it (this is the most useful)

We didn't design Kits for fontawesome.com

@rimmeh8

The funny thing is..... this is insanly bottlenecking the fonteawesome.com page too. It is loading an ridiculous amount of old webfont versions I stopped counting at 80 :D:D The Google Webfonts is going red when you add more than 3 to your Kit. And FA loads more than 80 OMG.

Our own site is a unique use case. We need to be able to display every icon and sometimes thousands on a page.

While we use some of the services of Kits on fontawesome.com, we didn't design Kits to be optimal for fontawesome.com.

We want Kits to be awesome for _your sites_.

Real-world examples of where performance is abysmall

@lumistu

I suspect this is actually the intended behaviour - i.e. it is loading the version of the font when the icon was introduced for every icon you are using. It does have a noticeable perf impact - I had one of my devs switch from CDN to a kit without telling me thinking it was a quick performance win. I noticed the perf drop immediately and went looking for the source.

You are correct. The general design of kits (loading many smaller files) is intended.

What we don't intend is for the peformance to degrade. @lumistu the problems you saw are exactly the type of thing we want to know about. Getting a HAR file from you that demonstrates the problems you saw on your project would be very valuable for us as we try to improve Kits.

@aidanlister

This is crazy ... why is this a thing?

Because it's new. Slightly innovative. And either browsers have changed some loading behavior or we missed something.

@robmadole this is not just happening for free kits - this is a paid kit and it's killing our site performance. We can't swap to the CDN version because we have too many subdomains.

I'm begging for HAR files! Begging. This would help us so much because _we need real-world examples of kit usage_ to know how we can improve it.

OK fine, I'll send you a HAR file because your begging is embarrassing

Send em to [email protected]. You can send "care of" any of the following titles:

• "Guy who takes forever to respond on GitHub Issues"
• "Mr. Begging For HAR Files"
• "Dude who over-uses Markdown in GitHub responses"
• "Rob"

[chiefGui]

Hey there!

Have you already done something about this matter, @robmadole? Because I read all the comments here and although it's true FontAwesome is making 1759735192 requests, need to say it isn't compromising performance on our app so I don't mind the amount of requests (nor our users). Yeah, the first load takes a bit longer but nothing we can't deal with.

BUT!

I came to this issue because of Chrome Developer Tools. I mean, it's part of my day-to-day work, and _after_ introducing FontAwesome, it became laggy and I have to wait until all the requests are made to be able to operate on it.

No doubt this is something you don't have control of, but at the same time I love the productivity of having icons by a <i class=""/> of distance, I'm loosing productivity when I need to deal with the console. I mean, I suppose DX also counts here, right?

Anyways, more a suggestion than a report.

Peace!

[alexandernst]

Why is this still a thing?

[ipontt]

Thank god the CDN is still available. Kits really screw up the loading times.

[yofreke]

Regarding Pro kits, they only load the webfont files that they need in order to show an icon. @lumistu if you are seeing a different behavior please provide some details.

I can confirm a "Font Awesome Pro, Latest Version, Web Fonts" kit that was made 22 days ago still shows this behavior, making ~700 requests on page load in my case. Switching to 5.12.0 CDN works as expected.

This is an example of a bug which can in theory be fixed promptly, now that there are kits managed by the FontAwesome service. The silence on this issue is pretty surprising, given it is a pro feature, and one affecting the FontAwesome Domain. @tagliala Any update from the FortAwesome team?

[tagliala]

@yofreke well, yes: https://github.com/FortAwesome/Font-Awesome/issues/15167#issuecomment-561270627 😅

[yofreke]

Oh wow, I somehow scrolled past that the first time.

Deploy our fix that improves kits using the "latest" version

Is there somewhere to track the progress of the availability of the deployed fix?

Change free kits to work like the CDN (loading a single large file instead of smaller files)

Will it be possible for pro kits to opt in to this new behavior?

[PoeHaH]

Crazy this is still a thing after so long. Experiencing the same issue.

[awhitford]

@robmadole Since you mentioned that you need metrics, will Google PageSpeed Insights reports help? You can see from my site's report that about 2 seconds are spent loading FA woff2 files -- see the Avoid chaining critical requests section.

[alexandernst]

@robmadole Please revert the overengineering you did here... Plain old CDN with a single font file was working extremely well...

[aidanlister]

Was anyone asking for versioned font awesome files?

Like I get the technical showmanship aspect: it’s impressive using HTTP2 to do that many requests in that short a time - only loading 1 or 2 icons as you go. It’s clever, and @robmadole’s implied point is that it might not be affecting performance as much as you think.

But ... it makes my Developer Web Console completely unusable, trying to find the AJAX request that fired at the same time as 5000 GET requests to FontAwesome. It makes first page load slow, and I’m sure there’s a CPU impact for that many HTTP requests (even if they are multi-plexed over HTTP2).

These things simply aren’t fixable, and they are not a trade off I want to make. I just want the latest version of the font awesome icons. That’s what I bought pro for.

Can we get a timeline on when pro kits with “latest” selected will be fixed? Going back to the CDN version is not an option as we have too many subdomains.

[BranonConor]

Anyone still having these issues? It's really messing up my work. I guess I'll just revert to the OG CDN??

[yofreke]

@awhitford fontawesome.com report 😅

[bfiessinger]

@yofreke as that might be a case pagespeed insights is not the tool while measuring performance issues. You can have a freaking bad score there and the real performance might still be good.

[PoeHaH]

@yofreke as that might be a case pagespeed insights is not the tool while measuring performance issues. You can have a freaking bad score there and the real performance might still be good.

Agreed, but still this is clearly an issue and nothing is been done about it for months.

[bfiessinger]

Agreed, but still this is clearly an issue and nothing is been done about it for months.

Totally agreed. I am following this post since it was started, hoping that somebody at FA will give it some more attention.

[robmadole]

Alright time for a quick update:

Summary

• The improvements to the free kits performance that I mentioned are about half way complete. Once we button it up we should be able to go out in 5.12.1
• The fix for "latest" version is done and we are planning the infrastructure rollout now (we've had some hiccups that need to be solved first)
• We don't have a firm date of release on either one

Details

@chiefGui

I came to this issue because of Chrome Developer Tools. I mean, it's part of my day-to-day work, and after introducing FontAwesome, it became laggy and I have to wait until all the requests are made to be able to operate on it.

Understood, thanks for sharing this. I'm assuming you are using a Pro kit? Is it SVG or Webfonts? About how many icons are you using on the laggy pages? Do you have "Disable Cache" checked in the dev console? (I normally do; just collecting info).

@yofreke

Will it be possible for pro kits to opt in to this new behavior?

No, not yet. We have other plans for Pro. The issue is that the Pro version is so much larger than free. We'll come back to Pro Kit performance at a later date.

@alexandernst

Please revert the overengineering you did here... Plain old CDN with a single font file was working extremely well...

What we'll do is continue to improve this service as we learn.

@aidanlister

But ... it makes my Developer Web Console completely unusable, trying to find the AJAX request that fired at the same time as 5000 GET requests to FontAwesome. It makes first page load slow, and I’m sure there’s a CPU impact for that many HTTP requests (even if they are multi-plexed over HTTP2).

Is this literally unusable or is it just hard to sift through the requests? Regarding CPU impact; we haven't seen this in our testing (it was statistically insignificant). Please share if you find out we are mistaken as we missed something or browser behavior has changed.

These things simply aren’t fixable, and they are not a trade off I want to make.

There is always the option to self-host and soon we hope to have the desktop subsetter available. However, I think we'll continue to make Kits better as much as we can. I don't agree that "things are simply [not] fixable". Just need some additional thought and a willingness to work hard at the problem with a good team of people.

@PoeHaH @basticodes

Agreed, but still this is clearly an issue and nothing is been done about it for months.

We've been actively working on it since I wrote the last "State of the Issue"

[aidanlister]

@robmadole what are the benefits of this approach though? I just want one fontawesome request to get all the latest icons ... why do I need thousands of requests? For what benefit are we jumping through all these hoops?

[tagliala]

I just want one fontawesome request to get all the latest icons ... why do I need thousands of requests

I think that if you use just a few icons, and maybe that's the average use case, getting those icons in individual http2 requests is better than getting all 7000 of them in a single one

[alexandernst]

@tagliala The point that @aidanlister is trying to make is that, overall, it takes less time to fetch a single file with 7000 icons than making hundreds of requests for icon files containing a few icons.

Aside from the download time, you have to keep in mind that a fetch request takes time to:

• connect to the server
• send request
• wait
• receive data

No matter how much of http2 and multiplexing you're doing, you still need to make hundreds of requests versus a single request for a bigger chunk of data.

[chiefGui]

@robmadole

Understood, thanks for sharing this. I'm assuming you are using a Pro kit? Is it SVG or Webfonts? About how many icons are you using on the laggy pages? Do you have "Disable Cache" checked in the dev console? (I normally do; just collecting info).

1. Yes, Pro Kit.
2. Webfonts.
3. About 80, perhaps? (It's a file management system, so icons out and about)
4. Yes, Disable Cache is checked.

[tagliala]

@alexandernst

you still need to make hundreds of requests versus a single request for a bigger chunk of data.

Even if I understand the needs of having a single request and I agree on having an option to choose which method use, I do not get the "hundreds of requests" for the average use case.

I've built a test page with 17 icons in all 4 styles using both Pro SVG Kit and CDN.

With fast 3G simulation, I get the following results:

https://tagliala.github.io/fa15167-cdn
First load: 3 (http2) requests, 1.8MB transferred, 11.93 seconds to finish, Load 11.32 seconds
Second load: 2 (http2) requests, 110B transferred, 593 ms to finish, Load 738ms

https://tagliala.github.io/fa15167-kit
First load: 22 (http2) requests, 26.5 KB transferred, 2.55 seconds to finish, Load 1.93 seconds
Second load: 2 (http2) requests, 158B transferred, 662 ms to finish, Load 630ms

[ipontt]

@tagliala What about the scenario where you're loading webfonts instead of svgs?

[aidanlister]

@robmadole please can we get an update on this? We're a paying customer, and this is such a clusterfuck ... I have a dozen developers complaining every day that they can't use Chrome Devtools to debug stuff any more because Font Awesome fires off 4000 requests each time we do an AJAX call.

I don't want this ... I can't use the CDN version because we have too many subdomains. Please tell me there's a light at the end of the tunnel.

[aidanlister]

Here's a video showing how ridiculous it is:

After a few interactions on the page FontAwesome has done over 5000 requests ...

and WHY ... who even asked for this feature of preserving icon backwards compatibility? What was the rationale behind this change??

[robmadole]

@chiefGui thanks for those details. Developer experience is certainly a metric we look at. I will put this on the work list as something we need to look at.

@aidanlister the behavior you are showing looks like there might be some other issue going on. I'd be happy to take a look if you have a URL but I suspect this is an internal site? (Is this site PJAX/Turbolinks? It almost looks like the Kit is being reloaded at every PJAX load to the server. Do you have the kit embed code at the end of the body tag?)

We will continue working on the developer experience but I think at this point you need to host Font Awesome yourself. Head to fontawesome.com/download and grab the download package. Those files are not split up by version delta (they are one large file). If you are hosting yourself it will also get you past the limitations of our Pro CDN service regarding your number of domains.

[ipontt]

@aidanlister I'm not a fan of this either but about the debugging... Can't you filter which request are shown in chrome dev tools? I know you can in firefox.

[aidanlister]

It's not pjax or turbolinks or anything fancy, each one of those clicks is react-select doing a lookup to a JSON endpoint. What's the font kit using to decide when it fires off 1000 requests?

[robmadole]

@aidanlister the Kit JS simply adds <link> tags to the head of the page. Those reference CSS files that reference web fonts. There is no JS that continues to run so it's just plain browser behavior.

[nortonandreev]

Seems like this has finally been resolved in 5.12.1, as promised.

[robmadole]

Yep, we just released 5.12.1 and it's generally available to everyone now. Anyone who was using an evergreen kit (version "latest") will already get this update on their site. We still have follow-up work to do on Kits but the main issue with free kits should be solved. (We'll follow up with the other work)

[robmadole]

I'm going to go ahead and close this and if there are follow-ups we can address that in new issues.

[supercodepoet]

Here is a blog post talking a little more about the issue we had with our Free Kits and what we were trying to do: https://blog.fontawesome.com/free-kits-a-retrospective/