Open varuniyer opened 1 year ago
I found I was able to improve the performance number by using https://purifycss.online/ to remove unused CSS from large stylesheets for things like material design bootstrap. I also moved all these assets previously fetched from jsdelivr to my repo. This brings the mobile performance up, but it's not consistently hitting 90+ on pagespeed.web.dev. I found the JS associated with some of these stylesheets like mdb.min.js also could be shrunken down since most functions there aren't being used. However, there are no tools like purifycss that I can use to remove these unused functions. Any tips on how one might go about removing the unused functions?
I'd like to update this saying I've managed to boost my mobile Pagespeed Insights score significantly by using the UnCSS CLI to generate smaller stylesheets that I store locally. I also improved the score by commenting out the script tag for mdb.min.js without experiencing any loss of usability. However, this may not be feasible for all al-folio users.
Maybe this solution could be incorporated. What do you think @alshedivat @rohandebsarkar @pourmand1376?
I found I was able to improve the performance number by using https://purifycss.online/ to remove unused CSS from large stylesheets for things like material design bootstrap. I also moved all these assets previously fetched from jsdelivr to my repo. This brings the mobile performance up, but it's not consistently hitting 90+ on pagespeed.web.dev. I found the JS associated with some of these stylesheets like mdb.min.js also could be shrunken down since most functions there aren't being used. However, there are no tools like purifycss that I can use to remove these unused functions. Any tips on how one might go about removing the unused functions?
About mdb
, once I removed and got some weird layouts, but don't exactly remember where.
jekyll-uncss may help incorporate performance improvements from removing unused CSS. As for removing mdb, I only removed mdb.min.js so the necessary CSS is still there.
While updating bootstrap dependency in #741, I felt that mdb
might not be required by many users considering its performance, so I added an option to disable it in the config file.
I don't think, using any tools to to remove unused CSS can be much helpful. This is because we may not require certain CSS and JS now but may require them later. In that case it will be a burden. Moreover different pages require different bits of CSS and JS, for removing unused bits we would have to scan through all the pages otherwise some pages may fail.
Yes, this is what makes jekyll-uncss desirable. Every user would have Jekyll generate different CSS files that reflect their usage even when starting from the same set of stylesheets.
I have been trying to use both jekyll-uncss
and uncss
, but to no avail. @varuniyer do you have experience with this?
I've used the uncss
CLI to reduce the file sizes. I haven't used jekyll-uncss
but I could look into a way to incorporate that if other maintainers think it would be worthwhile.
I believe this is worthwhile. Also, how much did the score went up for mobile?
My website's mobile performance score went up by around 30 points when using UnCSS-generated stylesheets. Now it's consistently 95+. However, I should mention that because UnCSS generates different stylesheets, I had to disable the hash-based integrity checking that al-folio currently uses. Also, jekyll-uncss assumes that stylesheets are loaded locally rather than from jsdelivr. Is this okay?
I think so. Is there a way to do this dinamically? I mean, download the correct version of the css and use the hash to check for its integrity, then only then do the uncss with it?
It should be possible to modify the jekyll-uncss source code to use a stylesheet URL and hash instead of a file name. You'd then add those arguments in the part of _config.yml
where you use uncss. However, we would then want to conditionally disable the integrity checks in _includes/head.html
when uncss is being used. I'm pretty sure this is possible. In that case, should I work on implementing this functionality?
No, it seems too much trouble. This would need PRs being submitted for the plug-in. Also, since the libraries versions are kind of "hard coded", I believe there is no problem in downloading and making them part of the repo. What do you think @alshedivat, @rohandebsarkar, @pourmand1376?
@varuniyer if you can, create a branch on your repo and share it here. Worst case scenario some users would apply it to their own repo (me included).
I have a mostly working branch here. To use it, you'd need to modify the build script to run npm install -g uncss
and export JEKYLL_ENV=production
(if you don't already).
Limitations are as follows:
site.baseurl
because uncss assumes JS files are locally stored in the directory specified by the src
attribute. For example, if site.baseurl
is set to al-folio
, it'll check _site/al-folio/assets/css
instead of _site/assets/css
.assets/plotly/demo.html
. To get around this, you can change the list of considered HTML files in the uncss
section of _config.yml
. Admittedly, this would be tedious if you had tens or hundreds of blog posts. localStorage
to get uncss
to work. This isn't a huge deal imo since localStorage
is only used to store the user's chosen theme.I believe in the 1st limitation, you meant
... instead of
_site/assets/css
right?
Regarding the second one, I believe adding a glob to check for html in the assets directory will work.
uncss:
stylesheets: # a list of stylesheets to be processed; mandatory
- /assets/css/*.css
files: # html files to consider, globs are supported; default: **/*.html
- "*.html"
- "**/*.html"
- "/assets/**/*.html"
I will give it a try later.
Yeah, in the first limitation that's what I meant. I've edited it to reflect that. For the second limitation, I don't think that would work since a user may need to include HTML files from a large directory except for 1-2 that use Plotly. Since uncss
has no way of ignoring specified HTML files, they'd have to list every single file in that large directory in the uncss
section of _config.yml
.
Ah, now I get it, it doesn't work with plotly demo. Maybe this is a thing the user might want to split in different directories while adding to uncss more carefully.
Yeah, it would be easy to leave them out if blogs with plotly went in a separate directory within _site
.
Since a lot has already been made to improve performance on mobile (currently we stand at 85 points) I don't know if we should close this issue.
An option to disable CSS/JS files for mdb in _config.yml
would be helpful for many sites (which don't need them).
What is it used for actually? When I tried to disable it ages ago it just changed the whole overall look of the site, that's why I left it there. But for sites that don't need them you can simply comment or delete it from the repo.
Makes sense, also most academics would probably be satisfied by these PageSpeed numbers anyways. I'm not sure how hard it would be to remove/replace mdb but at one point I got a minimal (no blog) site to work without it.
Is your feature request related to a problem? Please describe. It would be nice if the performance score from Pagespeed Insights was higher for mobile devices. Even though the desktop performance score is 93, the mobile performance score is only 54.
Describe the solution you'd like Looking at the Pagespeed advice, it seems the stylesheets are blocking render time on mobile. There may be a way to reduce the performance drop this has on mobile.
Describe alternatives you've considered Alternative academic websites like the Hugo templates have better performance scores on mobile.