Decreasing Fomantic UI footprint to the lowest as possible

[batata004]

Hi,

I have a collection of very specific websites that I really need to optimize CSS size and so far I got to reduce the "semantic.min.css" file to 215KB however 80% of the styles are not being used (according to COVERAGE tab of Chrome Dev Tools). So I decided to dig in and remove all unnecessary styles manully but things didnt go well, so my job was not good.

So far, my semantic.json file is like this:

"components": [
"reset",
"site",
"button",
"header",
"input",
"label",
"form",
"menu",
"message",
"item",
"checkbox",
"dimmer",
"modal",
"popup",
"transition"
]

I also setted site.variables to:

@importGoogleFonts : false;
@fontName : roboto,sans-serif;
@headerFont : @fontName;
@pageFont : @fontName;
@googleFontName : @fontName;

and colors.less to the minimmum possible.

Do you have any other suggestion of file that I can change (before executing gulp build) so the file semantic.min.css and semantic.min.js gets even smaller?

Checking the semantic.min.css I still see lots of stuff I really dont need like thousands of lines regarding "tertiary", "secondary"... thousand of lines about transitions that I never use (I only use the "scale" for the "dropdown menu" and "slide down" for the select element and nothing else)... thousand of lines regarding various button sizes, modal sizes... that I never use.

So I ask you, is there any other "granularity" change that I can make to allow the end files generated by gulp build to be even smaller? Or the changes that I did above (to "components", "site.variables" and "colors.less") are the most I can achieve?

OBS: before I take your time asking this I tried manually removing all the unnecessary lines BUT some things stopped working on mobile, on different screen resolution... I also tried some old Firefox that needed the -webkit prefix and things didnt go well after my "own manual clean up".

[prudho]

At the moment Fomantic cannot be reduced anymore without manually tweaking LESS files, which may lead to various issues. Maybe in the future it will be possible.

[y0hami]

@batata004 There is nothing you can do to not include the component variations unless you modify the LESS files directly like @prudho mentioned.

Try looking at https://github.com/purifycss/purifycss which should remove the unwanted styles.

[batata004]

@prudho thanks for you answer, it was not what I was expecting since I thought there should be some other optimizations, but it looks like there is none. :(

@hammy2899 Purifycss is a great tool but it has lots of problems. I am no one here to give advices since I am the one looking for help but there is a much much better tool already implemented on Chrome Dev Tools that already tells you all the classes being used in a website and the percentage! You just have to open Chrome Dev Tools, click on the 3 dots on the right -> MORE TOOLS -> Coverage. Click in the start recording button and reload the page. Start moving your mouse around the page, hover menu items, click on all the modals, reduce you browser/viewport width/height so you can simulate everything the user can do on your site.

At the end you can click on any file at the bottom of COVERAGE tab and it will tell you exactly what scripts/css classes you really used on each file you have on your website. THAT'S GREAT! But I still found some issues with it.

Purifycss is nowhere close to the Coverage tab cause with COVERAGE you can simulate user inputs, user navigation and check all the styles that are required. Purifycss uses a much much much simpler approach.

If any of you do check any website that uses semantic ui with the COVERAGE tab I am pretty sure you will realize 90% of the CSS/JS is never used. Never. That's sadly impressive! If you check that, maybe you will realize how terribly optimized is Semantic so far (not complaining, you surely already know that).

[samjudge]

@batata004 Unfortunately that isn't quite how it works - purifycss is a tool for static analysis of unused styles while the chrome tools are for debugging - it generates coverage reports by actually running the code (so cannot be used to reduce the actual size of the built files, since it needs to run them to begin with)

[y0hami]

@batata004 I would disagree, purifycss is doing it the more clever way since it is checking your files for usage were as the coverage tool in chrome will know what you have used on that page since it has to render and run it. The coverage tool won't cover all cases were as purifycss (or any other static analyser) will check for actual usage in your files.

I am pretty sure you will realize 90% of the CSS/JS is never used.

Just because you or lots of websites don't use something doesn't mean we should remove it since there will be users using these features. If the features are never used why would people request them? You have to remember lots of people who use SUI/FUI might not have their sites publicly facing so you can't get a true picture of what features are being used.

[batata004]

@hammy2899 and @samjudge I tried purifycss and the end resulted file was 13% of the actual semantic.min.css file. When using COVERAGE at the same site the end resulted file was 20% of the actual semantic.min.css. When I tested the file generated by purifycss with different screen resolution, it didnt work. It was very obvious: I have a form on some websites and the fields are arranged on 2 columns. When you reduce the screen width, semantic UI automatically makes the form be arranged in 2 columns.

When using the resulted file provided by COVERAGE it worked perfectly. When using the resulted file from purifycss it didnt work. Also other problems happened with purifycss: classes added with JAVASCRIPT to elements based on user movements of mouse were not in the end resulted file. Take for example https://www.sitepor500.com.br and scroll downn just a little bit the entrance. You will see some circles with logos inside. Hover your mouse over the circles. With purifycss this effect didnt work, with COVERAGE it worked perfectly.

The problems I had with coverage were more related to JS! It did a poor job optimizing JS and many errors happened on the console. HOWEVER, for CSS I am pretty sure COVERAGE did a nice job. BUT I dont trust it cause when I tried opening the website on a mobile I noticed some problems, even with COVERAGE. Purifycss on my mobile didnt work at all, the website was all "destroyed" with elements floating on wrong places and so on.

On my tests, clearly purifycss didnt do a good job at all. Coverage was much nicer. I even used the Canary (instead of chrome) cause in the canary version you can export ONLY the lines of code used very simple! The developer told me on next release of Chrome the "Export" feature will be available also on Chrome inside the COVERAGE tab.

Just because you or lots of websites don't use something doesn't mean we should remove it since there will be users using these features. If the features are never used why would people request them? You have to remember lots of people who use SUI/FUI might not have their sites publicly facing so you can't get a true picture of what features are being used.

Totally agree with you and I am sorry that I wasnt being clear. I provided support for thousand of websites and apps where I work and I am surely the one that can say that each website is different and there are a TON of use cases! A ton! BUT most of the time users use 2 or 3 colors of Semantic UI but they still have to load thousands of unused lines on their semantic.min.css file to support the other dozens of colors they will never use. Same is true with button sizes, most of the time people use 2 or 3 button sizes at most, but their semantic.min.css file will still be filled with thousands (literally) of lines with various buttons sizes that will never be used. Same is true with transitions, I am pretty sure you are fully aware of how many lines transitions consume on semantic.min.css file. They are A LOT! I really doubt any user will use more than 4 or 5 transitions on a website, if he/she does that I am pretty sure it's gonna be an edge case or a completely lack of good sense of design/usability.

I am all in regarding adding new features and make Fomantic code bigger and bigger! I am all in to make Fomantic "embrace" all use cases, as much features as possible! That's the main reason why the company I work for uses Semantic (now we moved to Fomantic) cause we can easily provide support for thousands of websites with a framework that simply works and is very powerfull.

I am all in to progress! BUT IT has to allow users to only choose what they are gonna use. Fomantic is huge, even if you use gulp build to select some components, many times you are with your hands tied. Take for example the component "transition" which is very very "heavy". I never "use it" directly, HOWEVER if I use modals (which is everytime) I need to use transitions. I need to load the entire "transition" component with thousands (literally) of lines of code on JS and CSS just to be able to make the window show up/close.

I think I am becoming very repetitive, sorry for that. I think I already made my point and I wont annoy you repeating the same complaining again and again like a child. Sorry for that. I know that you were completely aware (well before I say anything) of the "problems" I brought to you regarding lack of optimization on Fomantic. But I hope I gave you a small push on your efforts to give developers oppportunities to reduce even more their fomantic ui footprint you their websites.

[y0hami]

@batata004 I see your struggles but I honestly don't know what I can do about it, I have said we are working on this for v3 and it will be a big improvement. I am trying to make the build process so customizable that you can disable specific features etc. but again this will take time and we can't do anything about it for v2.

[batata004]

@hammy2899 Yeap, I was already told that :) I didnt want to be annoying opening this thread, I just opened it so I could provide you a use case and I was wondering if there was any other improvement I could do. Cause on other threads you guys told me about the "site.variables" and in another thread you told me about "colors.less" so I wanted to make sure I was not missing any other optimization that I could manually and easily do.

So I will close this thread, if you guys think of anything else I could go ahead and change I thank you! I wouldnt like to tweak a lot inside LESS files cause we need to keep all of our websites updated with libraries in their latest versions, so tweaking less files now, will require further tweaking later when updating library!

[hugopeek]

Although this issue is closed, just wanted to leave a quick note because I think everyone that uses SUI / FUI for building websites will probably experience the same as @batata004 to some degree. Myself included.

What proved absolutely vital in my case is Gzip. By default, my base library Romanesco weighs in at around 900 KB for the min.css and 250 for min.js. So that's pretty beefy and it won't get that much smaller by disabling some unused components.

Gzip however, manages to get the transferred CSS down to 120 KB and the JS to 60:

That makes things a whole lot more agreeable!