optimization in html and css

how do you optimize the images and makes the page load fastly ??

 

PNG is usually the LEAST efficient of formats unless you can optimize to 256 colours or less. Good rule of thumb is JPEG for photographs, PNG for line-art or anything that can be dropped in colour depth, GIF for anything that's less than 32,000 pixels in 16 colours or less.

Making a "speedy" page involves a lot of common sense that generally speaking pisses off the people dicking around in Photoshop and calling it design. The methods include:

1) Page Size Limits -- Generally speaking without counting content against a page on a normal website, there is NO legitimate reason other than developer ineptitude for a page to exceed 72k in 6 files. That's HTML + CSS + SCRIPTS + presentational images.

What are presentational images? Images that aren't part of the page content -- aka images that the page would make complete sense if they aren't shown. Icons, fancy bullets, the site logo -- all examples of that and have no business in your HTML and no business making the page break past those numbers.

A populated page (aka one with the content) I typically try to keep under 144k, with 256k as an upper limit, restraining myself to a dozen files if possible, two dozen or less being my upper limit.

While there exceptions to this (an image gallery being an obvious example since those are gonna be huge no matter what you do) if you can't built a normal page on a normal site under these limits, you're probably doing something wrong. Something like using the idiotic halfwit mouth-breathing bullshit known as "frameworks" that by THEMSELVES throw the page over these limits... Bootcrap, Jquery, Angular, YUI, Blueprint, Prototype -- JUST SAY NO.

This is your site... this is your site on frameworks. Any questions? Yeah, when does Waffle House open?

Even the markup should be able to meet certain size restrictions. A good rule of thumb?

expected markup size = 3000 + (plaintext size * 1.5) + (number of images/object/video/audio * 256) + (number of form elements * 128).

That's the "ideal" size -- If your markup exceeds these numbers by more than 50%, your markup is probably bloated rubbish. (again that's content images, presentation is NOT counted)

Let's use one of my sites as an example, lets pull the numbers for it's homepage:
http://www.ewiusb.com

The page total is 116k in 21 files. Of that 6 images totaling around 32k counts as content -- spitting distance from my ideal and well under the limits. The HTML for that page is 12.6k for 4.51k of plaintext.

3000 + 4625 * 1.5 + 6 * 256 = 11473 bytes.

So it's a hair over the ideal, but well under that 50% upper limit. SADLY most websites if you plugged in these numbers with the framework idiocy and other bits of nonsense, you end up with ten times or more the ideal -- and 99% of the time that's due to developer ineptitude, ignorance, and wishful thinking.

2) Separation of presentation from content -- The entire purpose of HTML is to say what things are, or what they would be in professional writing. As such as I often say "if you choose your HTML tags based on their default appearance, you are choosing the wrong tags for the wrong reason". Moving presentation out into an external stylesheet means that you can cache like-appearance across subpages, and pre-cache the appearance of subpages on first-load.

In addition to caching it plays to why HTML even exists in the first place -- device neutral delivery of content. HTML was created to say what things would be in a professionally written document so that the user agent (browser) could best deliver that within the limitations of the device it was shown on. We got away from that intent during the browser wars as Nyetscape and Microsoft went through a string of one-upmanship to try and add presentational crap to it, which led to the creation of CSS to say what things are so that the REAL HTML 4 (strict) could drag developers kicking and screaming back to using HTML for what it's actually for.

The TRUE ideal being that with HTML saying what things are, you can use MULTIPLE media targets to customize the appearance for each. Media queries simply extends what you can do with media targets.

All the above combines to why as a rule of thumb, if you are using the STYLE attribute, you are probably doing something wrong, and if you are using the <STYLE> tag, you ARE doing something wrong. If you are using IMG for something that's a background or presentation, you ARE doing something wrong, etc, etc.

3) File recombination -- techniques like the incorrectly named "CSS Sprites" can be used to reduce the number of separate files needed to build a page. This is particularly handy if you have lots of icons that are re-used a lot. The same goes for things like scripting and CSS where pasting them all into a single file can vastly speed up page load times.

Simple fact is that every separate file the first time you load a site has an overhead called "handshaking" -- the browser asks "do you have this file?", the server says "Yes I have that file", the browser says "can I have that file?" and the server says "Sure, on it's way" -- real world the BEST you are likely to see for that is 30ms overhead, but you'd have to be sitting on top of the server to ever see those numbers. REAL WORLD you should assume 200ms as the 'average' and up to a full on second or more as worst case.

This is why a site built from 90 separate CSS/JS/Image files can take anywhere from 16 seconds to a minute and a half of overhead REGARDLESS of the actual connection speed or size of those files.

Ever notice that when uploading via FTP that sending a hundred separate 1k files takes WAY longer than uploading a single 100k file? Yeah, that.

... and again caching helps with this since cached files only check for expires or changed after a certain period of time. If you have a relatively speedy first-load you can make subpages load even faster by precaching things like their CSS.

4) File optimization -- going through and using a program that actually knows how to encode files properly (Photoshop isn't it; Adobe wouldn't know file optimization from the hole in their product DVD's) can work wonders, but it also takes a bit of experience and experimentation. See above where I listed EACH file format for what it's good at? Yeah, that. No single format is perfect for every type of image. Photographs can typically take a bit of "damage" from a lossy encoder like JPEG and still be fine. Line-art often has long runs of the same pixels that make PNG the better choice. Low color line-art in small image sizes often work best in GIF.

Sometimes you just have to try saving it in each type to find out. I HIGHLY recommend "Paint Shop Pro" (now sold by Corel) as it has one of the best save-time optimizers out there, but tools like the GIMP do a decent job too.

There are also online image optimizers you can try, but I often find these to be flawed doing way more damage than sucking it up and using jpeg.

One big thing to avoid if possible is "alpha transparency" -- one of the big "features" of PNG it can increase the filesize 33% or more. While being able to have different levels of transparency across an image can be useful, it's a pain in the ass to create, results in a bloated file, makes the renderer in the browser have to work harder, etc, etc... This is made worse on the filesize front by PNG having piss poor compression of anything with more than a 8 bit colour depth.

There are times where it's your only choice to achieve a certain effect, but at that point I would start asking "Is this effect really important?"

5) Don't get in the way of what's important! -- and that means the CONTENT. Too often your PSD jockeys and scripttards will piss all over a site with "gee ain't it neat" garbage that you really have to ask "how does this help the user get to what they came here for, the CONTENT?" -- if it doesn't help with that, don't do it. Doesn't get simpler than that. While sure, it's easy to dupe the "suit with a checkbook" with something flashy, they'll be pretty pissed a few months later when said design is a money pit with nothing but bounce.

6) Avoid Frameworks -- I kind of already said this, but HTML and CSS frameworks are the leading cause of slow loading page bloat asshattery. Right now you have mouth-breathing dumbasses out there who see nothing wrong with sleazing hundreds of K of scripting and CSS out on pages that to be frank probably don't need more than 16k of each. AN ENTIRE WEBSITE has NO legitimate excuse to actually need more than around 48k of CSS and that would be for something like a forums. Really if you're going past 32k (uncompressed without minification) on the majority of designs there's probably something horribly wrong with your methodology, markup and general knowledge of site building.

I'd point out that the majority of frameworks uncompressed without minification are THREE TIMES that size before you even start writing your own code. WORSE, they usually make you bloat out the markup with endless pointless presentational classes, violating #2 up above!

Basically it's a case of "If you don't know what's wrong with this..."

<nav class="navbar navbar-inverse navbar-fixed-top">

Code (markup):

or this...

<div id="navbar" class="collapse navbar-collapse">
          <ul class="nav navbar-nav">

Code (markup):

... do the world a favor and back the **** away from the keyboard.

---------------------------------------------

Now all that said, do you have a particular site in mind for such optimizations? If you had a sample of what you are working on, we could probably dial in which optimization techniques would serve you best. It could also simply be you have a design that CANNOT be fast. This is particularly true if you've let some artsy fartsy type blow smoke up your backside tricking you into thinking that something like Photoshop is a web design tool... IT ISN'T.

MOST of the bloated art school idiocy and scripttardery commonly vomited up by the people calling themselves "web designers" right now having been built with such complete ignorance of HTML, CSS, emissive colourspace or accessibility that the creators of them have no business "designing" jack **** for anyone.

They're artists, NOT designers. It's like hiring Bob Ross to design your new skyscraper.

 

Caching is the best solution for this.
You can use varnish it will really speed up your loading!

 

Fast loading of the page isn't just achieved by fast loading of images: yes caching, but also uploading them on 3rd party server and loading from there to save requests for stuff you really need(.js, html, api calls..)
,async javascript execution where possible,order of execution(to prevent .js blocking css), constructing your page to look decent before images load and take up space)

 

Third party servers don't really "save requests" apart from load on the hosting server and to be frank, static file hosting isn't the giant overhead people seem to think it is. Compared to database access, static file serving is a drop in the bucket unless you have endless massive things like video or image content.

the BIG savings from serving off another domain is cookies. Any cookies your software sets domain-wide are sent with EACH file request REGARDLESS of file type in the HTTP headers. With things that track a LOT of massive cookies (typically for no good reason) moving files to another server saves that overhead in the HTTP headers. That's the number one reason to move static files to other domains -- even just making a parallel subdomain pointing at the exact same directory can make a huge difference in speeding up requests....

Since you know that back-and-forth handshaking I listed above? Yeah, cookies are sent each way on that as well.

I still say if you have enough scripttardery that it impacts CSS loading, you've got too damned much scripting. ADMITTEDLY the way halfwits, morons and fools are throwing idiocy like jQuery at EVERYTHING for no good reason other than developer ineptitude, it's not hard to see where delusions about things like ASYNC actually providing benefits comes from.

Quite often I WANT my scripting applied before styling is applied or the render is even shown -- because I'm manipulating the DOM and adding elements to it. That's why I load my scripts normally right before </body> and NEVER use scripting anywhere else in the markup. I don't use the onevent attributes, I never use document.write, and I generally try to avoid innerHTML for the same reason.

But sure, if you're one of these dumbasses with two dozen separate scripts totalling a megabyte and a half (like say, the halfwit dumbass default skin for vBull) then sure, you might see a benefit from playing those types of games. Too bad that doing so alienates probably more than half the potential audience at the same time.

Then the code bloat specialists run their mouths about "speed" when they've got a megabyte and a half of scripttardery doing zero to 32k's job.

 

Use Cloudflare. They cache your photos and your server will save resources because it does not have to serve the image on that request. Cloudflare will be like: " Oh you are requesting the same image, Ill serve the image instead of sending the request to your server "

If the image filename changes, then it will send the request to your server and cache the new image for future requests.

 

https://tinypng.com https://kraken.io

I think optimizing images will make the biggest difference (if they're not already optimized). Definitely the quickest way to cut A LOT off the page size. Gzipping also makes a huge difference if that's not enabled.

I wrote a whole post on this stuff, check it out:
https://sitechop.com/posts/12-speeding-up-your-website

 

From the 'fast internet' user experience,let's put backend code aside, sync api calls(e.q. jquery) and inline scripts are definitely something that takes a lot of load time. 5-6 fonts types also are sometimes being loaded, there is endless list of things that can be optimized(because some 'developer' code monkeys don't even bother about such things), but some are easy and really make a difference.

 

I would suggest to test your website page speed via Google PageSpeed Insight Tool - https://developers.google.com/speed/pagespeed/insights/. It will recommend things to do to improve your website page speed.

In my experience, not optimised images are the major cause of slow page speed. Save images for web and in proper size before uploading to your website. Other things you could do are:
1) Enable Cache: If your website is developed in WordPress, search some cache plugins and install the one you like. My favourite is W3 Total Cache.
2) Minify HTML and Javascript: Google PageSpeed Insight Tool will provide you minified HTML and Javascript. Use it. The downside of this is that HTML/CSS code becomes messy and takes time to make changes in the future.
3) Reduce server response time
4) Use Lazy Load plugin if pages on your website are long and have plenty of images. Lazy Load plugin is for WordPress.

You could also use Content Delivery Network (CDN). CDN delivers webpages and other web content to a user based on the geographic locations of the user. It may cost around 5$ to 10$ a month.

Good luck.

 

Lazy load is very useful if your page has a lot of image tiles, but in that case, these images should go in some scrollable box.

 

Just a quick tip for css : use minimized version for website.