FontAwesome Kit ruins Lighthouse site performance results

[alystair]

Describe the bug
FontAwesome Kit has a major impact on Lighthouse performance score. This probably represents real life performance implications on older mobile devices.

To Reproduce
Visit https://web.dev/measure/ or use Chrome's built-in Lighthouse in DevTools with default settings to test any site using a FontAwesome Kit /w SVG. Heck, running it on a simple page like https://fontawesome.com/icons/font-awesome-flag results in a performance score of... 4 (out of 100).

Expected behavior
FontAwesome JS should not block main thread in such an impactful manner.

Screenshots
https://fontawesome.com/icons/font-awesome-flag

Own site, larger impact

Version and implementation
Version: Latest (kit)
Browser and version: Chrome Version 79.0.3945.130 (Official Build) (64-bit)

• SVG with JS
• Web Fonts with CSS
• SVG Sprites
• On the Desktop

Bug report checklist

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

[alystair]

Related to #16077 in that they are both somewhat Lighthouse related, although this one is more critical from a performance perspective..

[alystair]

@tagliala Could you please tag this appropriately? ❤️

[tagliala]

Hi @alystair sorry for the late reply

Could you please provide a reproducible test case that is related to Font Awesome Kit rather than fontawesome.com documentation?

Auditing here is not that terrible: https://tagliala.github.io/fa15167-kit

[toomsbzh]

Hi, i have the same issue with random big response time. This problem is in your example too @tagliala.

[alystair]

at 4x slowdown, the fact that my entire web framework inits in 80-140ms best/worst scripting time compared to 210-420ms of the barebone demo you provided means something funky is going on.

Looking at FA's network graph alone I'd guesss instead of parsing the DOM first and collecting all outstanding icons for a 'batch' fetch, it starts fetching whilst parsing?

Using raw SVGs for our mission critical work for now... don't have time to drill down into the script/code.

[tagliala]

@toomsbzh Let's ask @robmadole if he is aware of random slow response time of individual svg files

---

@alystair

Looking at FA's network graph alone I'd guesss instead of parsing the DOM first and collecting all outstanding icons for a 'batch' fetch, it starts fetching whilst parsing?

Thanks for the hint. That demo is not optimized for performance, I'm just synchronously loading a kit in the head tag for other purposes, but I can see what you are saying and it looks it depends on how the Pro kit individually fetches the icons found

@robmadole could you please check if there is room for improvement here?

Using raw SVGs for our mission critical work for now... don't have time to drill down into the script/code.

I think that it is the best choice for your use case, and this should be one of the reason why we are providing individual svgs.

I think that loading the FA SVG framework, via cdn, kit or optimized pro kit, will introduce an overhead that does not seem compatible with your performance constraints

[alystair]

It's just overall concern for FA Kit overhead on mobile devices. There's probably room for optimization, which would allow for wider adoption :)

[robmadole]

@toomsbzh Let's ask @robmadole if he is aware of random slow response time of individual svg files

Yes, we've had reports about this. Our CDN provider and a lot of other providers are experiencing issues during COVID-19. @toomsbzh if this is a persistent issue send us an email at hello@fontawesome.com so we can take a deeper look.

@alystair FontAwesome Kit has a major impact on Lighthouse performance score

Our own site (fontawesome.com) is abysmal but our use case is pretty unique. Do you have a Lighthouse report for your own site?

at 4x slowdown, the fact that my entire web framework inits in 80-140ms best/worst scripting time compared to 210-420ms of the barebone demo you provided means something funky is going on.

That does sound funky. Do you have a test case we can take a look at?

Looking at FA's network graph alone I'd guesss instead of parsing the DOM first and collecting all outstanding icons for a 'batch' fetch, it starts fetching whilst parsing?

Correct. This is intentional. We also use requestAnimationFrame to defer the DOM updates in a batch. For Kits this is the performance trade-off we made. Luckily we have a lot of different ways you can use Font Awesome (with a JS framework like React or Vue, as sprites, with the subsetter, or individual SVGs). Depending on your performance needs we try to provide a solution.

It's just overall concern for FA Kit overhead on mobile devices. There's probably room for optimization, which would allow for wider adoption

We looked at mobile performance with Kits and didn't see anything problematic. If you have some evidence that we missed something we'd love to see some numbers.

I'm inclined to close this issues unless there is something specific we need to work on.