CSS Management, pageload speed, & BLOAT

[Geoffrey]

There are two reasons to seek optimal pageload speed:
1 - faster pageloads = more retained visitors
2 - google defines what it considers to be optimal pageload speed, and also provides recommendations for how to achieve it.  It seems unlikely that pageload speed is not a factor in their ranking algorithm. 

Following google guidelines, the biggest and easiest improvement i made to improve pageload speed was to combine and minify css. 
If you look in your head.tpl, you will see two things:
1 - calls for 5 separate css files.
2 - AC's notes on how to merge and minify css into one file, and even a link to an essay on css management. 

head.tpl calls 5 separate css files.  The bootstrap & font-awesome & style.css files are BIG.  My site uses a third or less of the rules in each of those files.

As a rule of thumb, all CSS files are render-blocking, meaning that the page cannot start rendering until all css files are loaded and parsed. 
It takes longer to call and parse multiple css stylesheets than it takes to call and parse one.
It takes longer to parse an un-minified css file than to parse a minified css file. 
Obvious solution: use a text editor to create a new css file called "bigboy" or whatever you want.  Then copy/paste the entire contents of each of the five oem css files into bigboy, then minify it and save it and upload it to your live stylesheet folder. 
Then edit your live head.tpl file to comment out the calls for the five separate css files and replace those with a single call for the new bigboy file. 

This dramatically improves AC pageload speed. 

But the job isn't really done, because most AC sites are like mine - they are only using a quarter or less of the rules contained in the oem css files.

The rest is just bloat. 

There are 2 methods I know of to get rid of this bloat:
1 - Firefox Dustme extension can identify unused rules in your css file, which you can then manually delete.  This is a labor intensive process that must be performed carefully over time, but you can shrink your bigboy css files from 9000 lines to 2000 lines pretty easily.  This will speed up parsing and therefore pageload, and will also make you feel less bloated. 

2 - There are scripts available on github that constantly screen oem css files to identify only those rules that are actually being used, and then combine and minify only the used rules into one small css file that runs the site.  You always work within the original separate large css files to make changes to your site, the script always runs in the background to include your modifications into the single small css file that the site runs on. 

Method 2 is much better in terms of longterm site maintenance, because the de-bloating and combining and minifying steps are automated, meaning that you don't have to undo and redo this process each time you edit your site within the oem files. 

Which leads to my questions: 
How do you use these kinds of scripts with AC?   
Has anyone done it? 
Has anyone tested any of the various different opensource css management scripts that are available? 
Is there a tutorial available on how to install and run these scripts on AC? 
Would you like to write one? 

I'd do it, but I don't even know step 1.

Thx. 

[Basara]

Hello.

First in list should be server/hosting! Then you should configure it correctly for example at least enable .htaccess optimizations

One of the largest content on your site are images, not CSS so consider to load all images with CDN network.
And be careful when you remove CSS rules. Default AbanteCart tempalte is responsive so CSS rule not working in desktop - will work on ipad or mobile screen. Test well after you made changes.   

http://docs.abantecart.com/pages/tips/performance.html

[Geoffrey]

Hi, for the sake of future readers who, like me, are not web development specialists, I offer the following comments:

Basara provides advice pertaining to AC features that should be enabled on any site:

1 - If you want fast pageloads, use a quality hosting company that provides reliable and fast server service. 

2 - Rename the oem .htaccess.txt file to .htaccess, and then add or uncomment various RewriteCond or RewriteRule rules within the file to accomplish the following objectives: direct all forms of url to your preferred url (ie www or https: or whichever you select as your primary site address), enable AC Retina screen image management, enable the AC SEO url, compression and cahce settings. 

3 - Use a content delivery network to deliver your site content, instead of having all of your content served only by your site host.  If you are Amazon, you need CDN, but you also buy web development, so none of my posts will ever mean anything to you.  If you are a small mom & pop with 30 products and 6 images of each product, my opinion is a CDN is not going to make a big difference in your pageload speed for most of your customers, provided that you have of course resized your images to site-appropriate dimensions and then optimized them with 4:2:0 chroma with 85% compression. 

Basara's final comments are related to my earlier paragraph that described FireFox DustMe extension.  The AC stylesheet obviously must include rules for various screen size breakpoints because AC is responsive.  As he says, the process of identifying unused rules must be accomplished over a period of time during which the site is thoroughly evaluated on ever conceivable screen size.  This is why Dustme is actually not a very helpful tool for a site such as AC that uses nearly 10,000 lines of css rules (unminified).  The hours spent manually deleting css rules over time would outweight the small gain reulting from reduced bloat. 

Which all brings us back to the central point of my post:
There are scripts available that apparently do a really good job over time of shrinking your css.  I wonder if anyone on the AC forum has made use of these scripts?  I wonder if the AC devs have considered them at all? 

Google webmaster tools include a speed assessment tool that measures pageload speed of your site in both mobile and desktop universe.  It is very simple to check speed, then change a site parameter and check speed again to see the effect of the change.  Google even goes so far as to make recommendations on how to improve your speed. 
This is how I determined that combining and minifying my css bumped me from high 70's to 90th percentile.  My site is almost what google considers to be fast. 

I'm quite sure that if shrink my css from 10,000 lines to 2000, I'll probably land at around 94, and i will have also done everything reasonable to optimize my site. 

Sooo, anyone had any success with css management scripts on AC or any other cms?

[Geoffrey]

In head.tpl,

Line 48 is a comment: "Set $faster_browser_rendering == true; for loading tuning."

Does that mean to set == true and leave it set to true, or

set to true for load tuning, but set back to false for production? 

[Geoffrey]

Follow-up:

grunt is a task performing app.

node.js is a js runtime environment you can install on a pc and use via command prompt.

Xenu's Link Sleuth is an old broken-link finder app that also spits out a sitemap if you want. 

grunt-uncss is a cooperatively created grunt task suitable for cleaning the css file for an html document.

grunt-contrib-cssmin is a grunt task that minifies css.

With node and Link Sleuth installed, you can create a sitemap of all site links, reformat the map into a url list suitable for grunt, set some limiting parameters for uncss, load the url list into grunt, designate target css files, and then run a grunt task that will clean out unused css rules and then output a minified file.

Two considerations:

1 - test your responsive functions after a cleanup.

2 - the vast majority of unused css in an AC site will be in the bootstrap and font-awesome files.  So if you tell grunt-uncss to ignore the other css files, then it will clean only bootstrap and FA.  This will cut your css filesize in half while minimizing the threat of nuking css rules that you actually need. 

There are two possible approaches to item2 above:
A - Target all css files, ignore all css files except BS and FA, then let grunt clean and minimize the batch. 
B - Target only BS and FA, let grunt-uncss clean them.  Then batch the cleaned BS and FA files with the other css files, and run another grunt task to combine and minify them. 

I haven't done this yet.  Maybe next week.  I will probably try a couple of different iterations, conservative vs. aggressive, and test to see what breaks.

I think my goal will be to do a big clean-up one time, archive the cleaned individual css files locally, make future edits to these files on a local site that runs on the individual files, combine and minify when finished with changes, and upload the new minified file to live server. 

Info:

i.   https://wireflare.com/blog/using-grunt-and-uncss-on-a-wordpress-site/
ii.   http://deanhume.com/home/blogpost/automatically-removing-unused-css-using-grunt/
iii.   https://github.com/addyosmani/grunt-uncss
iv.   https://gruntjs.com/getting-started
v.   https://nodejs.org/en/docs/guides/getting-started-guide/
vi.   https://moz.com/blog/xenu-link-sleuth-more-than-just-a-broken-links-finder

[Basara]

Hello.

Just few thoughts... You chose wrong approach. Cleaning CSS for default template will break something in descktop or mobile browsers. There are a lot of thing you can miss.

Better approach, if you still think smaller css file give you some benefit, is develop new template from scratch with minimum css you need

up to You.

[Geoffrey]

Hi, thanks for the feedback.

You make an important point that people should consider. 

I'm using a template extension, so the only css files I ever touch are the files in the extension folders.  I do not edit css files in default template folders. 

However, you can break the responsive capability either way. 

A few weeks ago, I used FireFox DustMe extension to evaluate my site.  Mostly what i learned: my site uses relatively few rules from bootstrap and onebyone css files, and almost none from font-awesome css file.  These three files account for about 70% of the total css load.  So if I cut the unused rules out of them, my total css load could be cut in half, maybe more. 

The css load is the last thing standing between me and a "fast site" score from Google. 

If I can try it local and test it for responsive function, no harm done. 

There are a lot of smart people in the world spending a reasonable amount of time discussing how to cut the bloat out of css boilerplate like bootstrap and font-awesome.  Who am I to say they are wasting their time?

As you know, I'm not a developer, so I think developing a template from scratch is not a better approach for me. 

[Basara]

You forgot about what if you decide to add something to your site later? Some specific block or option or even 3rd party extension which expect your site have full rules?

Also google score is just a suggestion. Consider to improve your site other way:
1. deliver your css or javascript faster - some cdn or another server
2. Improve server response time
3. optimize your thumbnails images

This is much more important for google than "some unused css rules"

After all of this my suggestion is to spend your time and effort to unique description and images. No matter how you site is supper fast if your content not unique you will be down in search results. Improve descriptions... maybe add some custom meta titles etc.

[Geoffrey]

Thanks for the advice. 

It's good advice.

For the benefit of future non-tech readers, I guess I'll add a few more comments.

If you make an effort to clean up CSS, your first step should be to backup and archive the full rule set.  You may need it if the cleanup breaks your site, and you may need it for future site mods.  It's not difficult to revert back to the full rule set.  Just delete the cleaned set, upload the full set, and edit head.tpl as needed.

Not to be argumentative, but a cdn is a geographically dispersed set of servers that attempts to load content to users faster by choosing servers closer to the user's location from which send all or parts of your content.  At nearly lightspeed, chopping 3000 miles off the content's journey will save less time than significantly reducing the filesize of the content.  I think cdn's must be a great idea for huge sites, but i see little potential benefit for small sites. 

If you're on a fast server already, this part of the job is already done. 

Optimize thumbs is a good idea.

Writing good content is essential. 
I worked hard to write good content, so i hope Basara's suggestion is more a general one, and not specifically directed at my site. :-)

If you choose a fast host, write good content, and optimize all images, and if everything else is running properly, your site will load fast. 
Mine does.  It's really pretty fast.

But if you want, you can also cut your css file load in half, combine and minify, and you will be even faster.  Does it matter?  Some say yes, some say no.  If you hack the css up, you risk losing responsive features or breaking your site.  That is why my original suggestion was to take a conservative approach. 

The uncss grunt was written by a google executive.  It has selectable levels and filters.  It is widely used. You can apply ignore blocks to all @media rules, etc, etc.  So if you spend just a little time during setup, it is quite possible to clean css without breaking AC, and it is always possible to revert. 

Closing comment: Basara gave good advice. 

[jackluter]

 thanks for the advice Geoffrey.
Site speed can make or break conversion rates and impact your site's revenue, so keep your page load time low by writing code semantically, use best practices and routinely cleaning up your CSS, HTML and images

[muneebqadar]

When you run an ecommerce websites, page load time should be 1.5 sec. Google considers it is a well developed and maintained site.

[carolanissa]

Spider bot of Google crawl every website and watch their page load time, Google bot loves 1 to 1.5 sec website loading time.

[accouconsult]

Great insights in this post! CSS management is often overlooked when optimizing for performance, but it plays a huge role in both page load speed and overall user experience. Bloat from unused or redundant stylesheets can quietly drag down site performance, especially on mobile devices or slower connections