How can I minify HTML and CSS File to improve the loading speed?

Hi dear Web Experts,

I am looking to improve the page speed of my website. I would like to know How can I minify HTML and CSS file to improve the loading speed?

 

As a rule of thumb, if minifying improves the loading speed, you've got problems. Both html and css are simple text. You could load the 800+ pages of Don Quixote in the blink of an eye. There are several other causes for slow speeds that need to be addressed before ever trying to use text minification.

gary

 

Since the question isn't clear at all (it's too generic), I'm afraid the only reasonable answer I can offer to you at the moment is this: go to search engine you prefer, type "minify css" and simply look for results.

 

You use Wordpress?
If yes, just install some additional plugin that will do all the tricks(Speed Booster Pack or any others)

 

I you use WordPress platform, then install the plugin 'Autoptimize'. If you use other platform, then find a plugin/module to do that. Then run 'Tools Pingdom' to check results of website elements loaded.

 

There are lots of css minifiers out there that will automatically minimize your css file. Google 'minify css' and you'll come up with lots of software to help you do just that. Just use caution about downloading (and scanning the downloaded files before using) and be sure to keep a backup of your original file in case the minifier changes something obvious that shouldn't have been changed. Good luck!

 

@kk5st I don't know about .css or HTML but when you minify large jQuery files the difference it makes is unbelievable.

But then again, you probably never use large jQuery files

 

You're right, I don't. jQ is a huge, bloated library laid on top of js. It shouldn't make a noticeable difference but with its size silliness, anything at all probably helps. If it makes an "unbelievable" difference, maybe you should look at how you're (mis)using scripts. If you're using jQ, the first thing to do is extract the parts you actually use and save them to your ad hoc library script. jQ encourages sloppy coding. I've actually had to fix/debug pages that used tens of kB to do nine lines worth of work. Further, scripts run as they're loaded which can block further loading until done. How many soi-disant devs do you know who write proper initialization scripts that run onload? I've even (all too often) seen jQ/js used to write static content.

But you knew I'd say that, right?

gary

 

Before you go nuts trying to minify things -- which more often than not when it comes to HTML and CSS is little more than sweeping bad code under the rug -- there are some things you should be checking.

1) How many SEPARATE stylesheets and scripts are you loading? Every time you request a separate file the 'overhead' of the request can run anywhere from 200ms to a full on second, as such the more separate files the page uses, the slower the loading time. In reality each request typically runs one second to five seconds, but because browsers can (in theory) request up to eight files at once, the "first eight are free" and we use 200ms as the "real world average" for each file after that.

As such if you have a page built from 68 separate files, the 'real world guesstimate" of handshaking time is 12 seconds REGARDLESS of connection speed. This can easily hit a minute or more if connection limits are choked out at the server, the user's machine, or any switch/router betwixt the two.

It's why if you're loading 20 separate scripts during the main pageload, /FAIL/ at web development. If you're loading more than one CSS file per media target, /FAIL/ at web development. Combining down those separate files can have a massive impact on your load times.

Likewise for things like icon images -- the incorrectly named "CSS Sprites" was created to reduce the number of handshakes speeding load time, and using fonts for icons (like font-awesome) serves much the same purpose; with the bonus of being vector / fully scaleable.

2) Are your static files being served gzipped by the server? gzip compression on HTTP can pay WAY bigger dividends than minification does and it's a hands-off approach once you implement it.

3) Are you using any 'blocking' scripting -- aka scripts that load inside <head>? Scripts that run during DOM creation because they use things like document.write? Either of those can hang the render and even loading of other files. That's why many developers have moved to placing ALL their scripting right before </body> and hooking the markup AFTER the DOM is built, instead of trying to manipulate it as it is built or telling the browser to load the scripting before the DOM.

4) Inlined scripting can also bugger things, which is why you shouldn't be using any onevent attributes in your markup, like onclick="". Your scripting should be hooking the markup with addEventListener. (with attachevent polyfill for legacy IE if necessary). Likewise you should when possible avoid putting scripting inside <script></script> and instead load it with <script src="external.css"></script>.

5) Do you have separation of presentation from content? This can lead to fat bloated slow loading scripting, hence why if you're using the <style> tag you're doing it all wrong, and in all but the rarest of corner cases style="" should be avoided. Moving as much of the presentation as possible out of the markup results in a smaller faster loading HTML AND allows caching models to kick in. If any like appearance is used on sub-pages the user navigates to, your external CSS file loaded when they first visit the page is cached, resulting in faster page-loads and lower bandwidth use.

6) Is it just too damned big for the job? Did you practice code-side targets during development?

I use a formula to determine how big markup for content SHOULD be, based on the practical needs of markup and content.

2048 + plaintext size * 1.5 + media elements * 256 + anchors * 128

"media elements' being things like iframe, object, embed, audio, video, and so forth. (though being 2018 we really have ZERO business using embed).

If your page's HTML exceeds that formula -- without wasting time on minification -- it's likely ineptly coded rubbish that needs to be pitched in the trash.

Likewise there is rarely any reason for an ENTIRE website to need more than 48k of CSS in ONE file per media target (such as screen, print, or aural). You have more than that, it's likely ineptly coded rubbish that needs to be pitched in the trash.

Same goes for the JavaScript, 64k is about the upper limit I'd allow NOT counting things like social media plugins. Social media is a 'necessary evil' of bloated code that's going to hurt, so the LAST thing you need to do is bloat out the page with your own scripting on top of that.

Much less how so much of the pointless "gee ain't it neat' scripting people throw at sites these days is a giant middle finger to accessibility and usability. JUST like the pointless bloated framework garbage -- like bootcrap and jQuacky -- pisses all over the place resulting in slow poorly developed ineptly coded sites. If you care about loading times, accessibility, and usability, you're not using frameworks.

Good Sun man, throwing more code at it is not the answer!

My God man, drilling holes in his head is not the answer! The artery must be repaired! Now, put away your butcher's knives and let me save this patient before it's too late! -- Leonard "Bones" McCoy.[/i]

 

Why not just use caching or HTTP2/nginx, load balancing to speed things up. There's ton of methods to increase load or execution speed. If you afraid of blocking, load or execute it in the background or accelerate GPU.

 

Use the server-side minification & compression by using this too: http://farhadi.ir/projects/smartoptimizer/