slice up twitter bootstrap to increase page load speed - html

I have designed my website to optimize the above the fold content by only using a tiny fraction of the twitter bootstrap framework above the fold of my site, then using some of the rest of it below the fold.
I used a floating nav bar that shrinks, some elements from the container class and that's all the twitter bootstrap content that's loaded above the fold.
I was wondering could I edit the bootstrap.css file to take out those portions and inline them in the head of my html page, then defer the loading of the rest of the css since I don't need it so fast.
My question; is it possible to edit the twitter bootstrap and just strip off the necessary parts to load first without wrecking bootstrap?

These are micro-optimizations which are only going to cause you headaches for very little, if any, benefit.
Unless you have a website which is serving millions of users a day or is displaying tonnes of content at once (and I really do mean tonnes, in which case, simplify your site!) you will see no real benefit with what you are proposing.
What you can do is be clever about what you optimize and how. For a start, if your entire site is only using certain portions of Bootstrap (i.e. you never use Modals), make a custom build of Bootstrap from their website with the stuff you don't want stripped out. This will give you a smaller set of files and therefore you'll send less down the wire to the user, speeding up your site.
Alternatively, if you are using large amounts of the library you could just use their existing CDN (content distribution network). This will serve the js/css files from a single url that many people are using, which has the double benefit that you don't have to serve any content from your own server, just link to someone elses, and also there's a good chance that if the user visited a site that has used that same CDN their browser would have cached it, making it appear without any network calls. Now that's speedy!
In the end, there are a whole host of things you would be better tasked at optimizing before even thinking about this kind of thing. I recommend you take a good look at the YSlow plugin and best practices. There are loads of things there that you can do to optimize your site without hacking apart Bootstrap just for 'above the fold' content.

Related

Twitter Bootstrap Response Time (Little Confused)

I'm in the process of making a project (website) and I needed some advice. My plan is to use NodeJS with the express webframework. I want to make this website really user friendly and nice just like everyone wants their website to be. The problem is that I might not be the most artistic meaning what I might think is artistic might actually not be artistic. My plan was to use Twitter bootstrap but I was scared of the response time of my website if I use bootstrap on my website. I feel like it might slow the response time of my website.
Is this true? Should I just stick to CSS + HTML to make it unique on my own or are there any other frameworks?
Thanks
If You add Twitter Bootstrap Framework from CDN, for example: http://www.bootstrapcdn.com/ there is a chance that people around web will have it cached by browser. But still, this framework is big (a lot of kB) and imho:
Pros:
maintenance is easy (complex documentation), so if You work in team with many people, it's easier to do it with any kind of framework
Bootstrap is large but customizable. You can get only some of JS plugins, and if You disable (for example in LESS version) some CSS stuff, it will be smaller
it's popular - cache advantage
Cons:
List item
big size and can affect page speed time

Is it more performant to have un-minified style in the HEAD or minified style in an external file?

I like the idea of encapsulating my CSS into separate files. This also brings the added advantage of being able to easily minify the CSS. But I know performance is negatively impacted by the overhead needed to pull these separate files from the server.
To address the latter point, people often suggest inlining the style or at least putting the CSS in the HEAD of the html document. I'm not going to inline because then editing the style becomes a nightmare. I can consider putting it in the head to increase performance, but I do not want to put it in there minified. I won't be able to read it, and it will be a pain to have to adjust the CSS once minified.
So my question is, What is the better option -- in terms of performance -- between these two?
Minified external CSS file
CSS placed in the HEAD but not minified
You are not considering browser-side caching in your evaluation. It is almost ALWAYS better to serve up CSS in an external file for cases where you will be using the same CSS file throughout a multi-page website. The reason for this is that once the CSS is downloaded on first page visit, assuming you have expiry headers set properly, the browser will not need to download the CSS on subsequent page loads until the expiry TTL is passed. This even holds true across multiple user sessions on a website, such that if a user visits the sites some days/weeks later, they may not need to download the CSS at all. If you served up in-page CSS, it would need to be downloaded on every page load.
Also minifying is typically not that big of a performance boost, as most server to browser connections will perform text compression on transmitted content anyway.
Of course it is also usually much easier to maintain CSS in an external file as you have pointed out.
The best option would be to:
Minify them all and bundle them in the server side with something like bundles for Asp.Net or brewer for nodejs, that way you remove the overhead you mentioned above.
To expand on my comment:
Generally, when optimising web page loading, you want to minimise the number of HTTP requests that the browser makes as these are expensive, time-wise; even requests for small files require the browser to send its request to a server, wait for the response, and then act accordingly. From that perspective, the best thing would be to put all the code for your page into a single file. However, this would be a page maintenance nightmare, and it also fails to take into account caching of resources by browsers, as covered by #MikeBrant.
A single css file (potentially composed of several concatenated minified files) is a good compromise between separation of style (css) and content (html), and performance. The same applies to javascript. You can also consider using a content delivery network (CDN) for Javascript if you're using a common library like JQuery as the user's browser may already have the library cached from visiting another site. Google's CDN serves a number of useful libraries.
Generally, you'll get far bigger performance gains from optimising images, enabling server compression, and removing extraneous javascript than you will from minification or inlining CSS. Images are almost always the "heaviest" elements of a page, and it is often very easy to reduce image size by 20-50% and maintain decent quality.

Minimize HTML page load time if it contains image icons

I want that my html page loads faster as it can. So I'm trying to put all CSS styles into the same .css file and all JavaScript code to the one .js file. How my colleagues told me it makes web page load faster. I want to ask some questions about it.
Just to be sure: Are my colleagues right? On which situations it's better to break CSS or JS code to the separate files?
Question is: If I have a lot of small icons on my page, like "delete, edit, add", should I load image with all icons at once or each icon separately? If I'll load all icons at once, how do I select desired one, if icon's size is 40x40px?
Thank you!
Are my colleagues right?
Single files can be downloaded with single HTTP requests (with single sets of HTTP headers, etc, etc) and can be compressed more efficiently then multiple files. So from a performance perspective, if you need all the content, it is better to place them in a single file.
On which situations it's better to break CSS or JS code to the separate files?
When you need a specific page to load very quickly (e.g. the homepage) or when there are sections of the site which use a large chunk of script that isn't used elsewhere then it can be beneficial to break the files up then.
If I have a lot of small icons on my page, like "delete, edit, add", should I load image with all icons at once or each icon separately?
From a performance standpoint, the same rules apply. However, there is no way to specify that a content image (and icons that don't decorate text are content images) is just part of a larger file. You have to use hacks involving background images. This breaks the separation of concerns around content and style and usually involves using semantically incorrect elements, and then requires further hackery to provide alternative content for users who can't see the image and that hackery rarely does as good a job as an alt attribute.
If I'll load all icons at once, how do I select desired one, if icon's size is 40x40px?
You have an element with specific dimensions and a background image with background-position set so that only the part of the image you want shows through.
Consolidating your CSS and JS code into a shared file will improve load times on all loads after the first so long as the browser uses the version of the file in its cache rather than downloading it again. There are many factors that can affect this, but under normal circumstances it should work.
Also, make sure your image files are stored in the same resolution as they will be displayed. Displaying a 40 x 40 pixel file at 20 x 20 pixels means that you have download four times the necessary image size. If the same icon file is referenced many places in an HTML document, then that icon file will only be downloaded once, so it will have little effect on page loading times.
For putting all the icons into one file and choosing which one, see this:
http://cssglobe.com/post/3028/creating-easy-and-useful-css-sprites
You can use what they call CSS sprite.
The thing is very simple to think of but can be a little tricky to use. Here is the idea.
You merge all your images into on big image, making it a single load.
Wherever these images were used on the site, you replace it by a css class which use the big image as a background and a certain positioning.
Let's say you merge 4 image together : delete.png, add.png, edit.png, share.png.
You create a css class for everyone of these like so :
.delete{ background-image:url('../img/icons.png');
background-position:0px 0px;
}
.add {background-image:url('../img/icons.png');
background-position:0px 40px;
}
.share {background-image:url('../img/icons.png');
background-position:40px 0px;
}
.edit { background-image:url('../img/icons.png');
background-position:40px 40px;
}
This way, you reduce the number of request since you you use a single image to show everywhere.
The code was written on the fly, tell if something is wrong.
Also have a look at performance guru tools : Page Speed
Breaking CSS files is not really a problem, considering browser caching.
Breaking up JS files is okay. You can have one JS that handles things needed for the page to load in the <head> tag. And one js that gives interaction to you, after </body>. By doing this you won't have various effects, but you ensure your users sees your text content.
Regarding your images, there's a practice called CSS Sprites. You can use that to make one big file for your small images and use CSS background-position to show only the part you want. It's like cropping your image file based on the css class.
If speed is most important, then what you've been told is correct.
Less CSS and JS files means less HTTP requests to the server. I would only separate files if you have a specific need as part of a project (eg they need to be maintained in ver separate ways)
For JS I always load JQuery and other libraries from the Google CDN - this has a greater performance boost that merging the library into your code as users are likely to have a cached version of Googles code.
For icons I would use CSS sprites (again this means fewer requests to the server) or if you really want to go as far as possible - look into embeding Data URI in your CSS.
Further reading
Googles Page Speed tool
Data URI in CSS
If you want a better performance report about your page, you can take a look at these tools
YSlow: http://developer.yahoo.com/yslow/
PageSpeed: http://code.google.com/intl/es-ES/speed/page-speed/docs/overview.html
Both can be added into the FireBug plugin (Mozilla Firefox).
From YSlow documentation:
Minify JavaScript and CSS
tag: javascript, css
Minification is the practice of removing unnecessary characters from code to reduce its >size thereby improving load times. When code is minified all comments are removed, as >well as unneeded white space characters (space, newline, and tab). In the case of >JavaScript, this improves response time performance because the size of the downloaded >file is reduced. Two popular tools for minifying JavaScript code are JSMin and YUI >Compressor. The YUI compressor can also minify CSS.
Obfuscation is an alternative optimization that can be applied to source code. It's more >complex than minification and thus more likely to generate bugs as a result of the >obfuscation step itself. In a survey of ten top U.S. web sites, minification achieved a >21% size reduction versus 25% for obfuscation. Although obfuscation has a higher size >reduction, minifying JavaScript is less risky.
In addition to minifying external scripts and styles, inlined and blocks >can and should also be minified. Even if you gzip your scripts and styles, minifying them >will still reduce the size by 5% or more. As the use and size of JavaScript and CSS >increases, so will the savings gained by minifying your code.
Preload Components
tag: content
Preload may look like the opposite of post-load, but it actually has a different goal. By >preloading components you can take advantage of the time the browser is idle and request >components (like images, styles and scripts) you'll need in the future. This way when the >user visits the next page, you could have most of the components already in the cache and >your page will load much faster for the user.
There are actually several types of preloading:
•Unconditional preload - as soon as onload fires, you go ahead and fetch some extra >components. Check google.com for an example of how a sprite image is requested onload. >This sprite image is not needed on the google.com homepage, but it is needed on the >consecutive search result page.
•Conditional preload - based on a user action you make an educated guess where the user >is headed next and preload accordingly. On search.yahoo.com you can see how some extra >components are requested after you start typing in the input box.
•Anticipated preload - preload in advance before launching a redesign. It often happens >after a redesign that you hear: "The new site is cool, but it's slower than before". Part >of the problem could be that the users were visiting your old site with a full cache, but >the new one is always an empty cache experience. You can mitigate this side effect by >preloading some components before you even launched the redesign. Your old site can use >the time the browser is idle and request images and scripts that will be used by the new >site
If you are using JQuery, then you can take a look at this: Preloading images with jQuery
Interesting concepts to improve download speed, perceived speed and actual speed:
7 techniques for faster JavaScript loading without compromising performance…
Make better use of caching
Download external scripts after visible content is loaded &
download multiple JavaScript in batch (asp.net/ajax)
Most principles explained are still generally applicable.

Mobiles, HTML, CSS (& laziness)

With regards to mobile websites on smartphones;
Assuming that:
HTML code is rarely a huge amount of data
Compressed JS files are not so heavy
Images are often loaded via CSS (at least could always)
It's the same sequence (PHP + SQL = HTML) on server-side.
It seems way faster to do this way and quite easy to maintain.
And even if:
It's not graceful at all (hide Useless elements instead of generating a sharp and beautiful HTML code)
Useless code is loaded and treated.
Best practices for mobiles websites don't recommend to do this way.
Is it a good idea to rely only on different CSS to create a mobile version of a website? (Actually on different header templates, in order not to load useless JS)
It's probably a bad idea to serve HTML with elements that you know will be useless to your users.
Small amounts of kb make a difference on mobile download speed.
It means your CSS and Javscript need to be more complicated.
You users might see the content if the CSS or JS are slow loading.
It will take more processing power (I think CSS styles will still be applied to the hidden elements).
It's likely to be easier to manage on the server
But to answer the question "Is it a good idea to rely only on different CSS to create a mobile version of a website?";
Yes if you want your mobile users to have the same content as your large screen users. Which you probably should as this is normally what the users want.
No if you want to serve them different content.
Speaking for Belgium, I know a lot of people are still on Edge instead of 3G and loading a webpage takes some time. If we would have to load pages made your way, we would indeed be loading a lot of useless code, giving us quite a bad experience.
I'd suggest you stop being lazy and write your mobile websites the way they should be written. Think of your visitors and user experience; it honestly isn't that much of an effort.
I think you basically answered your own question already. Like BoltClock said, do what you want, but I sure wouldn't recommend doing things your way.

Organizing css for large sites

I have a more general design question relating to css and websites. I know that it is good computer science to normalize code as much as possible and avoid duplication. So it would stand to reason to me, at least in theory that one would do the same when organizing stylesheets for a website.
So when I started on my most recent website I started out with this same philosophy. It worked ok for my first few pages and while I was only testing in firefox...
However as my site grew and as I added pages, multiple layouts (and browsers) I found this philosophy broke down really quickly. Ultimately over time I have moved to the following approach:
I have a very limited top level css file for each master page layout in my site, it contains classes for well known styles across that layout as well as css for the master page.
I keep specific css styles for each page.
I keep specific css styles for embeddable page elements / controls
I ended up taking this route so that I could trust that changes on one page wouldn't accidentally break other pages in the site resulting in a lot of regression bugs.
What do other people do when approaching this? Is this a good / bad approach... I do see cons to this approach, some pages are very similar so making a significant change means changing more css code, I also feel that the pro's outweigh this on a daily basis.
What do other developers think about this philosophy? Good? Bad? Just curious really...
To me its one of those situations where I weighed the difference between my ideals (I try to keep very tight code), and the frustration of changing requirements on one page breaking 20 other pages because I changed a div width by a few pixels (upsetting a float on another page for instance).
Thanks for your input
Just like any other type of code, if you are duplicating your CSS code all over the place, you are asking for trouble. Maintenance is going to get harder and harder for you as time goes on.
The best way to not have issues with a change on one page affecting other pages detrimentally is to have a style guide that drives your UI layout and design. If your style guide defintes the HTML and CSS classes to use for a given design element, then they will all always be displayed the same across all pages. If a specific page's element needs to be changed, you change the HTML to use a different class and then build new CSS for that class (and add it to your style guide for reuse). The style guide also allows you to make sure that your HTML is uniform across all developers working on the site, which means even less of a chance of CSS changes causing problems as you do more development.
Another point you need to remember with CSS is that every one of those .css files you create and reference on a page is an HTTP request. If every page and control has its own CSS file, you are really hurting your users' experience on the site by bogging down the total request download time for every single page request. It also makes it less likely for their browser to cache the .css files because the cache has a limited amount of space, so if you keep filling it with more and more .css files, they are going to get dumped from the cache more quickly. Yes, you can combine .css files programmatically in a handler so your page only makes one request per page, but then you have additional server overhead and the caching issue still remains (unless you have a single request for all .css files on your site, which defeats the purpose of what you're trying to do here anyways).