Jump to content

Font awesome 5.0


jair101

Recommended Posts

Font awesome is not the best solution. Why - because it provides a delay in loading site ... And the more new things create the more you will be delayed loading site.
I personally got tired of watching empty squares at the loading site. Perhaps it is good to look for other solutions.

For example - the three icons that load in mobile version navigation, I replaced with data images. Loading instantly ...:smile:

Link to comment
Share on other sites

  • 4 weeks later...
On 12/9/2018 at 5:18 PM, Adlago said:

Font awesome is not the best solution. Why - because it provides a delay in loading site ... And the more new things create the more you will be delayed loading site.
I personally got tired of watching empty squares at the loading site. Perhaps it is good to look for other solutions.

For example - the three icons that load in mobile version navigation, I replaced with data images. Loading instantly ...:smile:

Yeah, I am seeing where data images are the preferred method (although that does add to page weight (KB)) for faster loading.

Link to comment
Share on other sites

34 minutes ago, Joy Rex said:

Yeah, I am seeing where data images are the preferred method (although that does add to page weight (KB)) for faster loading.

yes, but the added weight is incomparably less. Font awesome causes a download of 65kB file and this slows rendering.

Link to comment
Share on other sites

1 minute ago, The Old Man said:

You can speed things up by only using the style of icons you actually need.

Or if you're willing to put in the work, you can download the icons you need as an svg file and host them locally. Added bonus is that's one less external call your site has to make.

 

Link to comment
Share on other sites

33 minutes ago, Adlago said:

yes, but the added weight is incomparably less. Font awesome causes a download of 65kB file and this slows rendering.

Only for the first visit - whereas using data:image means it's being downloaded on every page view. For a single icon (like your menu bars example) I'd agree that's the best approach, and that's what I do on my personal projects normally, but when we're using dozens of different icons in hundreds of places, it doesn't make sense.

That said, web development is always moving forward, so when our next major update begins, we'll evaluate the best approach at that point.

Link to comment
Share on other sites

3 hours ago, The Old Man said:

You can speed things up by only using the style of icons you actually need. 65kB is that small a file though, it's surely insignificant by today's broadband speeds, unless you're stuck still using a 14.4 kbit/s dial up modem! 

 

Pay attention - how late is the loading font awesome well after basic resources have been loaded - and the browser waits - that slows site rendering.
More curious is that this delay reduces the value of ads, of course for anyone who expects money from Google.

2119893245_Screenshotat2019-01-02224508.thumb.png.e395d19a28ef7acfe0d4efafb2f9fe80.png

I'm not worried about myself - I do not use ads. But I think the font awesome is a poor place in the suite.

The same delay, unfortunately, is also observed in 4.4 alpha.

Link to comment
Share on other sites

3 hours ago, Rikki said:

Only for the first visit - whereas using data:image means it's being downloaded on every page view. For a single icon (like your menu bars example) I'd agree that's the best approach, and that's what I do on my personal projects normally, but when we're using dozens of different icons in hundreds of places, it doesn't make sense.

That said, web development is always moving forward, so when our next major update begins, we'll evaluate the best approach at that point.

I agree that using data: image must also be refined and very carefully used. And here we have a reasonable compromise.
But I think there should be quicker decisions - I'm also looking for them.

Link to comment
Share on other sites

In your test, the file is being refetched from the server/host but for most end users the file will be cached in the user's browser after their first visit. This means that on every page load after the first, the font file does not need to be redownloaded or reprocessed.

Like everything in development, it's a trade off. This approach tends to be more efficient than multiple separate images, for instance. They may download in parallel, but will consume more storage space (and subsequently require more "management") and bandwidth. We feel our current approach is presently the best solution, but as Rikki said we will continue evaluating and if (when) a better solution becomes mainstream we will certainly use it.

Link to comment
Share on other sites

This test I do on this site as a guest - as every online tool does a test. Such an estimate speed makes and Google when analyzing the sites in which it publishes advertisements. This reduces the price paid by site owners.

Of course, users who logged into a site do not have this issue. But when it comes to money - any delay in loading site is bad. And I see many sites that rely on this ...

Link to comment
Share on other sites

2 hours ago, Adlago said:

This test I do on this site as a guest - as every online tool does a test. Such an estimate speed makes and Google when analyzing the sites in which it publishes advertisements. This reduces the price paid by site owners.

Of course, users who logged into a site do not have this issue. But when it comes to money - any delay in loading site is bad. And I see many sites that rely on this ...

It's cached for guests too after their first page load. You don't have to log in to get caching (in fact, our caching is even more aggressive for guests than members, since they all see the same thing).

Your tests are likely assuming an empty cache, which is a fair measurement of a first-time visit/stale cache, but subsequent page loads will be loading FA from cache, not the server.

Link to comment
Share on other sites

1 hour ago, Rikki said:

It's cached for guests too after their first page load. You don't have to log in to get caching (in fact, our caching is even more aggressive for guests than members, since they all see the same thing).

Your tests are likely assuming an empty cache, which is a fair measurement of a first-time visit/stale cache, but subsequent page loads will be loading FA from cache, not the server. 

For a normal users - you are right. Cache works correctly.
But when a speed test is done by a machine - incl. and these Google machines, these machines do not use cache. The http/2 protocol speeds up CSS and JS, but font awesome slow down a browser.
Here are three concurrent tests from different test server-
all reflect this delay.

936775486_Screenshotat2019-01-03205309.thumb.png.074ebbb9f2aec5b97639a7e9fd479cb8.png

126202690_Screenshotat2019-01-03205451.thumb.png.7bae2b45de46c5b93973f3f39b1dea57.png

1200562026_Screenshotat2019-01-03205508.thumb.png.6de423181db82b110bd3487799f0118c.png

Link to comment
Share on other sites

2 hours ago, ptprog said:

Has anybody tried to use '<link rel="preload" ...>' to load fonts?  Any idea if this improves performance?

Add in your globalTemplate before </head>

<link rel="preload" href="https://your site/applications/core/interface/font/icomoon.woff?v=-29n77j" as="font" type="font/woff" crossorigin="anonymous">
<link rel="preload" href="https://your site/applications/core/interface/font/fontawesome-webfont.woff2?v=4.7.0" as="font" type="font/woff2" crossorigin="anonymous">

 

Link to comment
Share on other sites

  • 5 months later...
On 1/4/2019 at 3:54 PM, ptprog said:

Has anybody tried to use '<link rel="preload" ...>' to load fonts?  Any idea if this improves performance?

Regarding performance, my experiments show a small degradation of performance (15% ~ 20%, measured with a RUM script) during the period I used the preload setting.

Link to comment
Share on other sites

  • 5 months later...

FA5 has been out for so long and had like a dozen releases that, I can't believe it still hasn't been properly integrated. Grumble, dropped the ball, mumble, mutter.... Just kidding. 🥰 The new FA5 extra icons packs are really nice. I wonder if IPS might one day release a SASS/LESS where CSS can be more quickly updated. 
 

Not had much time to test but a few days ago I tried out the new FA5 'kits' option with IPS4.4.8 and it certainly has great potential. Anyone else tried it yet?
You basically remove the existing FA4 import code and install one line of JS script to pull in your newly created kit, then on the FA5 dashboard site you can flick one of the toggle switches, and in theory it upgrades you on the fly to FA5, but better than the old 4-5 shim they originally released as a stop gap because it corrects any outdated icon codes and adds ARIA accessibility on the fly (i.e. all of them In the case of IPS!).

E45323AF-E264-4B82-9360-14B29FA37DB3.thumb.png.d63242bddb3eaaa9222e352fd0859ee4.png
 

58C543F8-3CCE-4082-83E9-0A2D3B32E346.thumb.png.b0c31266bc0449318ff0a65825a99dfd.png

 

It also only loads the icons you need, which sounds like a great performance boost. It allowed me to use Duotone icons. I tried the web font option first then the faster recommended SVG option, it worked but some icons seemed a bit off vertical alignment wise, on overlaid icons like the Twitter and YouTube social media buttons in the footer. So I switched back to the web font version for now, however it may be because I'd been editing the pseudo CSS a bit for something else just prior, so it may work as intended.

Edited by The Old Man
Link to comment
Share on other sites

20 hours ago, The Old Man said:

FA5 has been out for so long and had like a dozen releases that, I can't believe it still hasn't been properly integrated. Grumble, dropped the ball, mumble, mutter.... Just kidding. 🥰 The new FA5 extra icons packs are really nice. I wonder if IPS might one day release a SASS/LESS where CSS can be more quickly updated. 
 

Not had much time to test but a few days ago I tried out the new FA5 'kits' option with IPS4.4.8 and it certainly has great potential. Anyone else tried it yet?
You basically remove the existing FA4 import code and install one line of JS script to pull in your newly created kit, then on the FA5 dashboard site you can flick one of the toggle switches, and in theory it upgrades you on the fly to FA5, but better than the old 4-5 shim they originally released as a stop gap because it corrects any outdated icon codes and adds ARIA accessibility on the fly (i.e. all of them In the case of IPS!).

E45323AF-E264-4B82-9360-14B29FA37DB3.thumb.png.d63242bddb3eaaa9222e352fd0859ee4.png
 

58C543F8-3CCE-4082-83E9-0A2D3B32E346.thumb.png.b0c31266bc0449318ff0a65825a99dfd.png

 

It also only loads the icons you need, which sounds like a great performance boost. It allowed me to use Duotone icons. I tried the web font option first then the faster recommended SVG option, it worked but some icons seemed a bit off vertical alignment wise, on overlaid icons like the Twitter and YouTube social media buttons in the footer. So I switched back to the web font version for now, however it may be because I'd been editing the pseudo CSS a bit for something else just prior, so it may work as intended.

I only played with FA5 few times myself as really like the feel of the icons vs FA4 never noticed the toggle for loading both normal just use css to fix the issues between the to,

Link to comment
Share on other sites

  • 3 months later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...