Modern browsers support gzip/deflate compression and http pipelining, which helps speed up my page being loaded by the client's browsers.
I came across a great technique for optimizing images, so I was wondering if there is a way to bundle css/js/html (the plain text) files together into a single stream so that my web pages can be delivered faster.
Your help is kindly appreciated.
Regards,
Richard
There are several minification projects out there.
Google minify is one example.
Minification tends to not go as far as you are suggesting (bundling css/js/html into one stream), but combining all CSS into a single request and JS into a single request (as well as removal of insignificant whitespace and sometimes renaming of code to shorter variables).
I presume you've had a look at the excellent YSlow add-on for Firefox which gives some excellent tips on speeding up download times.
You can certainly combine js / css files on the server before being downloaded, but you wouldn't want to actually combine the html+js+css into a single stream. The simple reason for this is browser caching. The js and css files are only downloaded once, then your html is downloaded for every new page. If the js and css are combined into the html, then essentially every page is different and nothing be cached.
Related
Looking at the source of a website today I came across something that surprised me. They had the images included in the css file (see http://static.a.gs-cdn.net/webincludes/css/production-uri.css?20120521.1)
This surprised me, surely loading one large file with all the images embedded would take longer on a modern browser (ie chrome fires off lots a simultaneous requests for the content it needs) and make it harder to debug any css issues. Is that correct and are there any advantages to this approach?
There's nothing really wrong with including images in CSS, although it may be more efficient to use CSS sprites.
It makes sense to use CSS sprites for UI elements (but not content elements) because it reduces the number of HTTP requests.
This is a good article detailing a few of the pros and cons of such an approach.
Pros:
The biggest reason: it saves HTTP Requests. Other than pure document size, this is the #1 factor concerning how fast a page loads. Less = better.
Cons:
It's hard to maintain site with embedded data URIs for everything. It's easier to just update an image and replace it.
You should only use this in documents that are heavily cached, like your CSS should be. Having a CSS file that is 300k instead of 50k is fine if it saves 6 HTTP requests, but only if that CSS file is cached just as well as those images would be.
Personally, I never use it. It saves on HTTP requests, but bloats your CSS with things that are, in my opinion, not appropriate. For a clean separation of concerns, images should be just that - images.
Plus, you'll have a harder time caching all the resources - if you make one change to your CSS, that's all the image data getting re-downloaded for no reason.
Many people say to keep the number of external CSS and JavaScript files to minimum to reduce round trip time. For example, Google recommends maximum two CSS and JavaScript files per web site, respectively.
The problem is, I've broken up CSS code into several files depending on its nature as part of "modularization". For example, I've put CSS code that is only used in a certain part of the application in a separate file. As a result, some files have less than a hundred lines of code.
I'm a Java develper, and this is actually a recommended practice in Java, but CSS is a totally different creature and I don't know much about CSS. Here are my questions.
Does it make sense to keep as many CSS files as you see fit for readability and maintainability?
How many CSS files are manageable in a web project?
What's the average number of CSS files in web applications that you've worked on in the past?
The best solution is to write a script that combines (and minifies) multiple CSS or JS files.
You might benefit from a solution like Bundler, or Chirpy
http://www.codethinked.com/bundler-now-supports-css-and-less
http://chirpy.codeplex.com/
We use chirpy because we found a bug in Bundler that can inject query string params into you css files.
As a bonus to file consolidation, you also get .less syntax handling.
I agree with what other have said here, yes when you develop you have muliple CSS files, but for production you should merge an minify them.
However I do not agree you should merge them all into 1 single file. As the will mean people who just want to visit your home page must wait for CSS on pages x,y,z also to download.
What I usually do is have 2 or 3 CSS files.
1 small CSS file just for the home page only so it load super quick so casual visitors do not have to wait to see what my site is about
Another CSS file for every other page availble to guest users
Another CSS file for a members only sectons of the website that require a login.
You can also use scripts like HEAD.JS which will manage your CSS and javascript asynchronously
From there site http://headjs.com/
There is a common misbelief that a single combined script performs best. Wrong:
latest browsers and Head JS can load scripts in parallel. loading 3 parts in parallel instead of as a single chunk is usually faster.
if an individual file is changed the whole combination changes and you loose the benefits of caching. it's better to combine only the stable files that doesn't change often.
many popular libraries are hosted on CDN. you should take the advantage of it instead of hosting yourself
iPhone 3.x cannot cache files larger than 15kb and in iPhone 4 the limit is 25kb. And this is the size before gzipping. if you care about iPhones you should respect these limits.
As you point out, having multiple CSS files often leads to better maintainability and modularity.
The number of CSS files needed depends on the size of your project and the level of modularity in the project.
Serving up on CSS file instead of many often makes a noticeable difference in the page loading time, so the ideal solution is to have some kind of tool that combines, and maybe even compresses, the CSS files. This can easily be done in runtime by a tool such as Minify.
Combining resources can be beneficial in that it can reduce the number of HTTP requests; Reducing the number of HTTP requests certainly lowers overhead and can improve performance. It can also have benefits for caching, in that there can be fewer objects in the cache.
That said, this kind of optimization is only useful with metrics. There are profilers out there (Firebug has one) that can show you how many requests you're making and how long they take. You may (or may not) find there are more time-effective ways to increase performance and reduce load on your server.
I've been monitoring the Net panel of Firebug and noticed that the HTML has to be downloaded first before any other resources are downloaded. I guess this make sense since the other resources are defined in the HTML. Is there a way around this so that other components can be downloaded during the HTML download?
Debugging 101: what you see while debugging is different than what happens when you are not looking.
Most browsers start the HTML interpretation while downloading it, and start downloading the additional resources concurrently. Firebug is not a great place to see that happening, try HTTPFox instead.
Now, to answer your question: you don't need to do anything to make the browser download the other components while downloading your HTML, it'll take care of that for you.
No - the browser needs a parseable HTML document first before it can start downloading scripts, images, etc.
You can speed up downloading of the non-HTML elements by moving them to different subdomains though: Browsers have a connections-per-host limit which is circumvented by using subdomains. Additionally you could compress/minify your CSS/JavaScript files to reduce their size.
There is the potential for one to create a small HTML file that then makes several requests to fill in the rest of the page through various AJAX-like calls, but if someone has JavaScript disabled then the page may look really bad. In a sense this is taking out some of the original HTML content and having it be downloaded separately which may or may not be a good idea. In a sense though this is using more network resources as there would be many requests to fully load the page in this case but it is a question of what is an acceptable trade-off.
I'm wondering if it's better to make one or several files for CSS files ?
I always see websites with a plenty of css files, but it seems better to use only one large file.
What's your advice ?
Performance wise, you are better off with a single file, as it results in one connection and request to the server (these tend to be expensive operations, time wise).
This is why minifying frameworks exist, that merge together all the CSS (and JavaScript) files for each page and serve them in one request.
My strategy on this is simple.
I separate production from development, both in CSS files and in JS files.
in development, I can have up to 20 JS files and 10 CSS files, organization is super slick and easy, I always know where everything is.
In production, all files are minified into 1js and 1css file, changes are always made in development and then "staged" to production so I gain the maintainability of the application and the performance in production.
I use Yahoo minifier to minify my files but you can use whatever is convenient for you.
Having one CSS file doesn't just help with HTTP requests, it will also give you better compression (compressing one big file should give you better results than compressing multiple smaller files).
Different HTTP requests are hardly the bottleneck here, file size ultimately is. The reason it's best to split things up as much as possible is because if you want to change a certain thing of your site's feel, let's say, the font of all headers, you want to change one file / setting only for that, and want that file to be as small as possible.
For large and encompasing CSS, I would make different CSS documents for all different things like the layout, the treatment of classes, and so on, another advantage is that if you've multiple pages that need a slightly different look from the main page, they only have to link to one other CSS file, not to a completely different one, the majority they an share.
If performance does matters to you
Then
If your site is small but gets huge traffic then go for one css file
if site is small personal or business sites then but with less traffic then go to multiple css
If CSS files maintainability does matters to you
Then
If your site is small with less different pages then go for one css file.
if site is big then go for multiple css http://www.killersites.com/blog/2008/how-to-organize-css/
HTTP request of CSS files will not make big difference in performance of small site.
Use not too much different css files or at least try to put them on other domains to speed up downloading them by the browser. I also suggest you use a minification tool.
Well, the same as Yahoo!'s: Use one to reduce the number of HTTP requests.
For the quickest download and rendering of a page, the Yahoo performance rules are correct. You want as few http requests as possible.
However, on many sites, it's simply not convenient to have a single large CSS files. Your best bet is to organize your CSS into as many files as you'd like, and then use a server side script to concatenate the files. GZIP'ing that file goes a long way, too.
you should use more than one css file rather using one big file. It helps you while maintaining your site also use different definitions (classe or id names) in different css otherwise it will take the one which declared later.
But for performance reasone you can use one large file because,
One large CSS file leads to fewer HTTP requests, which can improve performance.
Several smaller files leads to easier organization which will make development and maintenance cheaper and easier.
Multiple files are good for organization, but one request to the server is definitely best. If you watch the performance videos from Google they suggest the least amount of HTTP requests possible. Each HTTP request has overhead in the handshake that you do not want to incur if you wish your site to be fast.
Check out this great script which will take your multiple CSS/JS files and turn them into one file:
http://code.google.com/p/minify/
Weigh it up.
The advantages of one CSS file
Reduced latency. Each downloadable component comes with a small amount of latency. Less files => less latency
Single point of compression
Advantages of multiple
Change one file won't require all css to be re-downloaded. The other css can be served from the cache
Structure
Only download what you need. If you don't have any forms on your page for example you don't need to download forms.css
I use simple javascripts, jquery library and many plugins , should i make one file for all if yes then what we need to "just copy and paste and code from all file into one in needed order" or any thing else need to be considerd.
as stated here http://developer.yahoo.com/performance/rules.html#num_http
Combined files are a way to reduce the
number of HTTP requests by combining
all scripts into a single script, and
similarly combining all CSS into a
single stylesheet. Combining files is
more challenging when the scripts and
stylesheets vary from page to page,
but making this part of your release
process improves response times.
and this http://developer.yahoo.com/performance/rules.html#js_bottom
The problem caused by scripts is that
they block parallel downloads. The
HTTP/1.1 specification suggests that
browsers download no more than two
components in parallel per hostname.
If you serve your images from multiple
hostnames, you can get more than two
downloads to occur in parallel. While
a script is downloading, however, the
browser won't start any other
downloads, even on different hostname
It these are god practices then
How to combine multiple javascript ito one without getting any conflict?
Is it just same as i copy all css code from all files into one or it's tricky?
For each file you have, there are two steps :
send the HTTP request to the server
download the content of the file
If you reduce the number of files by combining them, you will reduce the number of HTTP requests -- which means your page will load a bit faster ;; which is good for your users ; which is why it's recommended.
But this will make debuggig harder, which is why it's recommended to do this only on your production environment, and not on the development platform -- hence the "making this part of your release process" part.
Of course, the process of combining your files content should not be done manually -- else, you'll have to re-do it each time there's a modification made ; it should be fully automated, and done at the time you are building the archive that is going to be deployed on your production server.
Also :
You might gain a bit on the "dowload" part if using minification
You will gain a lot more on the "download" part if using compression (see mod_deflate, for Apache)
Ideally, you can use all three solutions, btw ;-)
Placing the <script> tags at the end of your page will :
allow the content of the page (which generall is what matters the most) to be displayed faster
but will only work if your page/JS is coded "correctly" (i.e. unobstrusive JS, not using JS "hardcoded" in the HTML page)
This can help too -- but might be a bit harder to achieve than combinaison+minification+compression.
There are several methods for improving javascript load performance.
Combine scripts into one file: I suggest only combining scripts you write/maintain yourself. Otherwise if the 3rd party library is updated it could be tough to update your combined file.
Use JSMin to reduce the size of javascript files, see http://www.crockford.com/javascript/jsmin.html.
Use Google's CDN for referencing JQuery and JQuery UI, see http://code.google.com/apis/ajaxlibs/documentation/, eg:
<script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'></script>
This avoids the user loading the file at all if their browser already has it cached.
For JQuery, you should be loading from Google. Since a lot of places use Google's JQuery, it's likely that it will already be cached and even potentially compiled on the user's machine, which is about as good as one can possibly get. Cache beats all when it comes to JS optimization.
If you're using one set of JS files across all the pages on the site, you can get a similar effect by combining them into one file and using it everywhere; the browser will load it on the first page the user visits and then the JS will be cached.
However, if each of your pages uses a different set of files, the cache benefits will be vastly reduced and in fact it may be counterproductive, since the browser will detect a+b.js as a different file and will load it even if a.js and b.js are already cached. Additionally, combining the files in the right configurations for each page is a non-trivial dependency-tracking problem. In short, it's more trouble than it is worth unless you're serving millions of unique hits per day, and even then it might not be a good idea.
In any case, minification and compression should always be applied in production, since they have basically no downsides.