24 Essential Pages to include on Your Website

May 1, 2009 · Leave a Comment
Filed under: Creative Website Design, Featured, General 

24 Essential Pages to include on Your Website
By Ivana Katz (c) 2009

Wondering what pages to include on your website and why? Here is a list of important information that should be included on your site.

Before you start thinking about what to write, it is important that you create a plan, which outlines what each page will contain. That way you won’t repeat yourself or forget vital information. The most common pages on successful websites include:

1. Home Page (First Page)

This is your “sales” page and should provide information about what you can do for your customers. It should also give your visitors a brief overview of what they can find on your site.

2. Products / Services

It is useful to have a separate page for each product/service and write as much detail about each as possible. Start each page with a brief summary of the product/service, then provide whatever information you can. When people are searching for information on the internet, they want to know it NOW. They don’t want to wait until tomorrow when they can speak to you on the phone.

3. Contact Us

Place contact details in as many places as possible. Make it easy for your customers to contact you. Create a special “Contact Us” page and include your details in the “About Us” page and also at the bottom of each page. Information to include: business name, physical address, mailing address, telephone, fax, email, emergency number, website address.

4. Pricing

Whenever possible include the price of your products/services. Even if you can’t be specific. It is helpful to put at least a range of prices, eg. Carpet cleaning ranges between $40 – $60 per room.

5. Testimonials / Product Reviews / Before & After

Include testimonials from your current customers to show your potential clients that you are trustworthy, reliable and that you offer great service and/or products. Make sure the testimonials are real and if possible provide contact details of the person who supplied you with the testimonial. If you don’t have any right now, get them! Simply email your customers and ask for their feedback on your business and service.

You could also include before and after photos. Show the problem picture and beside it show the picture of resolution, with an explanation of your product’s benefits.

6. Frequently Asked Questions

This has proven to be a great time saver for many companies. Instead of having to answer the same questions over and over again, place them on your website and keep adding to them. The more information you have on your website, the less time you will need to spend answering questions by email or phone.

Frequently Asked Questions should address your customer’s concerns that may otherwise be an obstacle to making a sale.

7. Response form such as “Subscribe” or “Enquiry” form

An absolute must if you want to build a mailing list. Most people don’t like giving out too much information, so ask only the basics, such as Name and Email Address. Then keep in touch with your customers on a regular basis by sending out information that may be of interest to them. You may even wish to develop your own on-line magazine (ezine). There are many fantastic free or inexpensive programs that can handle this for you.

8. On-line Magazine or Newsletter

This is a great marketing tool. Not only does it help you keep in touch with your customers, but provides your website with fresh content. You can set up your Ezine in 2 different ways:

(a) Email subscribers on a regular basis, or
(b) Publish it on your website.

Or both. Include information about your business, industry or anything that may be of interest to your customers.

9. Resources/Articles

Add value to your business. Provide information that is complementary to what you do. For example, if you sell wedding dresses include information about reception venues, wedding planners, wedding cakes, flowers. By adding extra information you encourage more hits.

10. About Us

This is a very important page as it tells your customer about who you are and why they should buy your products, services and/or trust your organization. It can also feature your business hours (if you have a bricks and mortar store) or when they can speak to someone on the phone. Many companies also include their mission, details of their staff (photos, biographies, qualifications), recently completed projects, ACN or ABN, logo, directions to your store/office. It is also useful to include details of trade associations you belong to, trad

e and insurance certificates and any awards you may have won.

11. Guarantee

Offer a money back guarantee. The longer the guarantee, the more effective it will be. It could be 30 days, 60 days, 1 year or lifetime.

12. Survey




Find out what customers think about your website, business or product.

13. Events Calendar

This can relate to your business or industry. If you are an artist, you can feature dates where and when your art will be displayed or if you are a singer, where you will be performing.

14. Search My Website Feature

Some visitors to your site may not know exactly what they want, but if you include a search function on your site, they can look for it very easily. Like search engines, this feature will allow your visitors to type in a word or phrase and then search for it on your site. It’s like having your own mini search engine, only instead of it searching the world wide web, it just searches your website.

15. Return/Refund Policy

To make your customers feel more comfortable when making a transaction at your website, you should provide them with your return/refund policy. Ensure it is easy to understand and spelled out step by step.

16. Privacy Policy

Privacy continues to be a major issue for customers shopping online. Concerns about how their information is going to be used is a major barrier when making a sale. Internet shopping experience is built on trust and privacy is the number one ingredient in trust.

17. Site Map

A site map shows visitors how the site is laid out and which sections are where.

18. Copyright Information

Your website should carry a copyright notice to protect its intellectual property. It is generally in the form of “Copyright (c) 2004, Your Company Name”.

19. Links

Here you can place links to the manufacturers of your products, trade associations or complementary services. When you place links to other businesses, you can request they do the same for you. This will not only bring you more visitors, but may improve your search engine ranking.

20. Media Information

Include any information, articles, photos of your products, staff etc that have appeared in the media – print, TV, radio or internet.

21. News

This can include news about your products/services or about your industry.

22. On-line store

An on-line store allows you sell products directly on the internet 24 hours a day/7 days a week. When building an online store it is important to take in a number of key concepts.

  • Make sure that when visitors arrive at your store the navigational mechanisms are simple and effective.
  • The actual process of placing the order must be simple.
  • Make sure you accept common and convenient methods of payment.
  • Continually test your store so you understand your customer’s shopping experience.

23. Blog

A blog is a journal that is available on the web. The activity of updating a blog is “blogging” and someone who keeps a blog is a “blogger.” Blogs are typically updated daily or weekly using software that allows people with little or no technical background to update and maintain the blog. Blogs are a great tool because they help with:

(a) Communicating with your customers. Blogs provide a way for you to communicate with your customers directly. And it is a two-way communication. You can post a message on your blog and your visitors can easily respond.(b) Search Engine Marketing Blogs give you an increased presence on search engines, like Yahoo! and Google. If you use Blogger (Google’s Blogging Tool), every message you post creates a new page on Google so in a very short time you could have lots of pages pointing to your website.

(c) Stay Ahead of Your Competition Blogs are relatively new and chances are your competition does not yet use them. So you will be seen as an expert in your industry when you post your knowledge and expertise.

(d) Media & Public Relations Blogs are excellent PR tools. You can post your Media Releases and articles and have them picked up by the media.

(e) Free or Low Cost

24. Photo Gallery

Even if you do not wish to sell your products on-line, you may wish to showcase your goods or services in a special photo gallery – show how your products or services are being used by your customers. They say “pictures speak a thousand words” and on your website it is particularly important.

Don’t give your customers a reason to visit your competitor’s website and provide them with all the information they may possibly need or want.

 

7 Basics of Good Web Design

May 1, 2009 · Leave a Comment
Filed under: Creative Website Design, Featured, General 

 

7 Basics of Good Web Design
By George Peirson (c) 2009

Whether you are just starting a web design project, looking at revamping an existing site, or just wanting to double check the usability of your current web site you should consider these 7 Basics of Good Web Design.

These basics are aimed at new visitors/customers; your repeat customers will be judging your web site on different values. Just like wearing the appropriate clothes for a job interview, these basics will help you pick out the “look” of your web site so that you make a good first impression.

1. Fast Loading Web Site – Any way you look at it, a fast loading page should be your number 1 concern. The web is all about speed, fast searches, fast purchases, fast information. You can’t have any of that with a slow loading page. Ask yourself this question – have you ever been on Google doing a search for something important and a link you clicked on didn’t open up immediately? What did you do? Patiently wait for the page to open or move onto the next link on the list? My favorite sites open almost immediately.

So, a few suggestions: Make sure that your images are properly optimized. Don’t use very many large images, save those for a different page. Keep any auto-running multimedia to a minimum, offer links to run media instead. Check your code for anything else that could affect your page loading times. Since text loads almost instantly go ahead and use all the text you want, just keep everything else under control.

2. No Meaningless Splash Page – Do you appreciate a fancy animation page that doesn’t tell you anything and you have to wait for before the web site will open? Neither do I. The last thing I want once I find an interesting site is to wait through some animation before getting to the first page. This doesn’t mean that I don’t want multimedia on a site, I do. I just don’t want an animation before the first page that forces me to wait for it to finish before getting onto the site. It’s like having to wait for a salesperson to finish their memorized speech before you can ask them a question. No thanks! I like animation, just in the right place and at the right time. Plus, if I am a returning customer, I will have already seen that animation and don’t need to see it again.

My recommendation is to use a smaller animation contained in your main landing page which also includes your main message and links to the rest of your site. It will make for a faster loading page (smaller file) and your visitors can go ahead with accessing your site without having to wait for the animation to finish.

One final note, never, ever put your logo as the only content on your landing page with a link that says “Enter Site”. This just screams Unprofessional and will drive away potential visitors in droves. The last thing I want to do is to click on another link just to get into the site. This is a total waste of my time. I usually will skip a site if I see this.

3. No Annoying Web Gimmicks – Now that you have your visitor on your site quickly the one thing you don’t want to do is to drive them away just as quickly. So, don’t put anything annoying on that first page. No loud background music that makes them quickly hit the volume control or the back button on their browser. No flashing animations while they are trying to read your content. No popup, flyout, expanding ads that cover your home page. Basically, leave the gimmicks alone until you are sure that your visitor will stay on your site. Most casual visitors will leave your site in just a few seconds, no sense on driving them away more quickly.

Multimedia is great on a web site, just don’t bombard your visitor with it first thing. If you want audio, then put in a nice picture with a link, like a picture of yourself with text saying something like “Let me tell you how to make $50,000 this month!” If they are interested, they will click on the link and listen to your message; if they are not interested in audio, then you should be using a different pitch anyway.

Also, monitor what advertisers are putting on your site if you sell ad space. I am sure you have seen those ads with the animated dancing figure, cute the first time you see it. But after seeing it 10,000 times with every imaginable character I have added the company to a list I keep of companies I will never do business with. So their animation has gone from “look at me” to “you annoy me” in my mind. Ads like these will impact your visitor’s experience. So even if your site is perfectly designed, one misplaced ad can ruin all of your hard work.

4. Have a Clear Message – Too many web sites are a mish-mash of content. This is especially true of blog pages. Certain types of sites lend themselves to stream of consciousness content, but most don’t. Make it easy for your viewer to understand what your web site is about, don’t make them guess. Have a clear topic headline, followed by clear and concise text. This is also where a picture is worth a thousand words, but only if the picture directly pertains to your message.

You want your visitor to quickly understand what your message is. If they like your message, they will take the time to read the rest of your page and look around your web site. If they don’t like your page, then it won’t do you any good having them stay on your site anyway. So, don’t make your visitors guess, let them know what you are about quickly and cleanly and you will have happy visitors. And when thinking about a sales page, a happy customer is a buying customer.

5. Coordinated Design – This one should be self evident, but it is surprising how many sites change their design for every page. You want your visitor to be comfortable in your site and one way to achieve that is by having a coordinated web design. Having a consistent logo, using a consistent color scheme, keeping your navigation in the same place. All of these help to create a coordinated design. This does not mean that you can’t change colors or the “Look” on different segments of your site, but if you do, the changes should not be so drastic that it feels like you have moved on to a different site.

If you select one place for your logo, one place for your navigation, one look for your buttons or other common graphic elements and stick with those then you will be well on your way to a coordinated design. If you change colors for a different section, but keep the same logo location, the same navigation location, the same button shape, then your visitors will not become lost as they move from page to page.

6. Easy Navigation – Once you have grabbed your visitors attention you want them to be able to easily move around the different areas of your web site. This is done with easy to use navigation. There are three standard, accepted locations for navigation elements on a web page: along the top, on the left side, and at the bottom. I will usually put my main navigation either along the top or along the left side. I will then put text based navigation at the bottom of the page, this text based navigation is more for the search engines than anything else, but it also makes it easy for your visitors to move to the next page when they have reached the bottom of the current page.

Most people start reading a page from the top left and then read towards the bottom right. So navigation at the left or top will be seen as soon as someone enters your page. Also navigation at the left or top will not move or change position if the browser window is adjusted in size. The worst thing you can do is to put your main navigation on the right side of the page and have your page set for a large screen size. Let&

#8217;s say that your page is set for 1024 across with the navigation on the right, and someone views your page at 800 across, they will not see your navigation at all. The left side of your page will show perfectly, but the right side will be hidden outside of their viewing area. Of course by using floating or popup menus you can overcome some of these design limitations and keep your navigation visible at all times.

Unless you know that your audience will enjoy it, don’t use Mystery Navigation. This is where your navigation is hidden within images, or spaced around the web page in some mysterious random order. This can be fun on gaming sites, or social networking sites, but in most cases the navigation should be easy to see and easy to use. If you do want to use Mystery Navigation, I would recommend keeping the text based navigation at the bottom of the page, just in case.

7. Have a “Complete” web site – And finally, no one wants to go to a web site only to find that the site is “Under Construction” and the content they are looking for is not there. These are words that you should never use. If a section of your web site is not ready for prime time yet, then simply don’t show it yet. It is better to have your site look complete and professional, then to have it look like a work in progress that should not be up on the web yet.

You can easily tell your visitors that you will be having more content in the future without having your site look like it is unfinished. Just use phrases like “Content Updated Weekly” or “New Products Added Monthly”. Both of these will tell your visitors that it would be worth their time to come back and visit later, but neither one will make your site look unfinished. So no matter how small your web site is, give the impression that you have taken the time to complete the site before putting it up on the internet, this makes for a more professional presentation and a better visitor experience.

In Closing – By following these simple 7 Basics of Good Web Design you will be well on your way to having an easy to use and successful web presence. Just keep in mind what you look for when you first land on a web page after doing a web search in Google or Yahoo, or other search engine. If you want fast loading pages, make sure your pages load fast. If you want to be able to find what you are looking for quickly and easily, then make sure you have easy navigation. Just keep your first time visitor in mind, put yourself in their web shoes and make your web site an enjoyable place to visit and success should follow.

 

Web 2.0 validator

Enter a URL to find out if the site is really Web 2.0

And validate that is your site a web 2.0 standard

http://web2.0validator.com/

Special Entities

February 3, 2009 · Leave a Comment
Filed under: Featured, Special Entities, W3C, Web 2.0 

The following table gives the character entity reference, decimal character reference, and hexadecimal character reference for markup-significant and internationalization characters, as well as the rendering of each in your browser. Glyphs of the characters are available at the Unicode Consortium.

With the exception of HTML 2.0‘s ", &, <, and >, these entities are all new in HTML 4.0 and may not be supported by old browsers. Support in recent browsers is good.




































Character Entity Decimal Hex Rendering in Your Browser
Entity Decimal Hex
quotation mark = APL quote " " "
ampersand & & & & & &
less-than sign < < < < < <
greater-than sign > > > > > >
Latin capital ligature OE Œ Œ &#x152; Œ Œ Œ
Latin small ligature oe œ œ &#x153; œ œ œ
Latin capital letter S with caron Š Š &#x160; Š Š Š
Latin small letter s with caron š š &#x161; š š š
Latin capital letter Y with diaeresis Ÿ Ÿ &#x178; Ÿ Ÿ Ÿ
modifier letter circumflex accent ˆ ˆ &#x2C6; ˆ ˆ ˆ
small tilde ˜ ˜ &#x2DC; ˜ ˜ ˜
en space
em space
thin space
zero width non-joiner
zero width joiner
left-to-right mark
right-to-left mark
en dash
em dash
left single quotation mark
right single quotation mark
single low-9 quotation mark
left double quotation mark
right double quotation mark
double low-9 quotation mark
dagger
double dagger
per mille sign
single left-pointing angle quotation mark
single right-pointing angle quotation mark
euro sign

Entities for Symbols and Greek Letters — Special Characters

February 3, 2009 · 1 Comment
Filed under: Creative Website Design, CSS, Featured, W3C, Web 2.0 

The following table gives the character entity reference, decimal character reference, and hexadecimal character reference for symbols and Greek letters, as well as the rendering of each in your browser. Glyphs of the characters are available at the Unicode Consortium.

These entities are all new in HTML 4.0 and may not be supported by old browsers. Support in recent browsers is good.































































































































Character Entity Decimal Hex Rendering in Your Browser
Entity Decimal Hex
Latin small f with hook = function = florin ƒ ƒ &#x192; ƒ ƒ ƒ
Greek capital letter alpha Α Α &#x391; Α Α Α
Greek capital letter beta Β Β &#x392; Β Β Β
Greek capital letter gamma Γ Γ &#x393; Γ Γ Γ
Greek capital letter delta Δ Δ &#x394; Δ Δ Δ
Greek capital letter epsilon Ε Ε &#x395; Ε Ε Ε
Greek capital letter zeta Ζ Ζ &#x396; Ζ Ζ Ζ
Greek capital letter eta Η Η &#x397; Η Η Η
Greek capital letter theta Θ Θ &#x398; Θ Θ Θ
Greek capital letter iota Ι Ι &#x399; Ι Ι Ι
Greek capital letter kappa Κ Κ &#x39A; Κ Κ Κ
Greek capital letter lambda Λ Λ &#x39B; Λ Λ Λ
Greek capital letter mu Μ Μ &#x39C; Μ Μ Μ
Greek capital letter nu Ν Ν &#x39D; Ν Ν Ν
Greek capital letter xi Ξ Ξ &#x39E; Ξ Ξ Ξ
Greek capital letter omicron Ο Ο &#x39F; Ο Ο Ο
Greek capital letter pi Π Π &#x3A0; Π Π Π
Greek capital letter rho Ρ Ρ &#x3A1; Ρ Ρ Ρ
Greek capital letter sigma Σ Σ &#x3A3; Σ Σ Σ
Greek capital letter tau Τ Τ &#x3A4; Τ Τ Τ
Greek capital letter upsilon Υ Υ &#x3A5; Υ Υ Υ
Greek capital letter phi Φ Φ &#x3A6; Φ Φ Φ
Greek capital letter chi Χ Χ &#x3A7; Χ Χ Χ
Greek capital letter psi Ψ Ψ &#x3A8; Ψ Ψ Ψ
Greek capital letter omega Ω Ω &#x3A9; Ω Ω Ω
Greek small letter alpha α α &#x3B1; α α α
Greek small letter beta β β &#x3B2; β β β
Greek small letter gamma γ γ &#x3B3; γ γ γ
Greek small letter delta δ δ &#x3B4; δ δ δ
Greek small letter epsilon ε ε &#x3B5; ε ε ε
Greek small letter zeta ζ ζ &#x3B6; ζ ζ ζ
Greek small letter eta η η &#x3B7; η η η
Greek small letter theta θ θ &#x3B8; θ θ θ
Greek small letter iota ι ι &#x3B9; ι ι ι
Greek small letter kappa κ κ &#x3BA; κ κ κ
Greek small letter lambda λ λ &#x3BB; λ λ λ
Greek small letter mu μ μ &#x3BC; μ μ μ
Greek small letter nu ν ν &#x3BD; ν ν ν
Greek small letter xi ξ ξ &#x3BE; ξ ξ ξ
Greek small letter omicron ο ο &#x3BF; ο ο ο
Greek small letter pi π π &#x3C0; π π π
Greek small letter rho ρ ρ &#x3C1; ρ ρ ρ
Greek small letter final sigma ς ς &#x3C2; ς ς ς
Greek small letter sigma σ σ &#x3C3; σ σ σ
Greek small letter tau τ τ &#x3C4; τ τ τ
Greek small letter upsilon υ υ &#x3C5; υ υ υ
Greek small letter phi φ φ &#x3C6; φ φ φ
Greek small letter chi χ χ &#x3C7; χ χ χ
Greek small letter psi ψ ψ &#x3C8; ψ ψ ψ
Greek small letter omega ω ω &#x3C9; ω ω ω
Greek small letter theta symbol ϑ ϑ &#x3D1; ϑ ϑ ϑ
Greek upsilon with hook symbol ϒ ϒ &#x3D2; ϒ ϒ ϒ
Greek pi symbol ϖ ϖ &#x3D6; ϖ ϖ ϖ
bullet = black small circle
horizontal ellipsis = three dot leader
prime = minutes = feet
double prime = seconds = inches
overline = spacing overscore
fraction slash
script capital P = power set = Weierstrass p
blackletter capital I = imaginary part
blackletter capital R = real part symbol
trade mark sign
alef symbol = first transfinite cardinal
leftwards arrow
upwards arrow
rightwards arrow
downwards arrow
left right arrow
downwards arrow with corner leftwards = carriage return
leftwards double arrow
upwards double arrow
rightwards double arrow
downwards double arrow
left right double arrow
for all
partial differential
there exists
empty set = null set = diameter
nabla = backward difference
element of
not an element of
contains as member
n-ary product = product sign
n-ary sumation
minus sign
asterisk operator
square root = radical sign
proportional to
infinity
angle
logical and = wedge
logical or = vee
intersection = cap
union = cup
integral
therefore
tilde operator = varies with = similar to
approximately equal to
almost equal to = asymptotic to
not equal to
identical to
less-than or equal to
greater-than or equal to
subset of
superset of
not a subset of
subset of or equal to
superset of or equal to
circled plus = direct sum
circled times = vector product
up tack = orthogonal to = perpendicular
dot operator
left ceiling = APL upstile
right ceiling
left floor = APL downstile
right floor
left-pointing angle bracket = bra
right-pointing angle bracket = ket
lozenge
black spade suit
black club suit = shamrock
black heart suit = valentine
black diamond suit

Web Site Optimization: 13 Simple Steps

August 24, 2008 · Leave a Comment
Filed under: Creative Website Design, Featured, W3C, Web 2.0 

Earlier this year, Steve Souders from the Yahoo! Performance team published a series of front-end performance optimization “rules” for optimizing a page.

This tutorial takes a practical, example-based approach to implementing those rules. It’s targeted towards web developers with a small budget, who are most likely using shared hosting, and working under the various restrictions that come with such a setup. Shared hosts make it harder to play with Apache configuration — sometimes it’s even impossible — so we’ll take a look at what you can do, given certain common restrictions, and assuming your host runs PHP and Apache.

The tutorial is divided into four parts:

  1. basic optimization rules
  2. optimizing assets (images, scripts, and styles)
  3. optimizations specific to scripts
  4. optimizations specific to styles
Credits and Suggested Reading

The article is not going to explain Yahoo!’s performance rules in detail, so you’d do well to read through them on your own for a better understanding of their importance, the reasoning behind the rules, and how they came to be. Here’s the list of rules in question:

  1. Make fewer HTTP requests
  2. Use a Content Delivery Network
  3. Add an Expires header
  4. Gzip components
  5. Put CSS at the top
  6. Move scripts to the bottom
  7. Avoid CSS expressions
  8. Make JavaScript and CSS external
  9. Reduce DNS lookups
  10. Minify JavaScript
  11. Avoid redirects
  12. Remove duplicate scripts
  13. Configure ETags

You can read about these rules on the Yahoo! Developer Network site. You can also check out the book “High Performance Web Sites” by Steve Souders, and the performance research articles on the YUI blog by Tenni Theurer.

Basic Optimization Rules

Decrease Download Sizes

Decreasing download sizes isn’t even in Yahoo!’s list of rules — probably because it’s so obvious. However I don’t think it hurts to reiterate the point — let’s call it Rule #0.

When we look at a simple web page we see:

  • some HTML code
  • different page components (assets) referenced by the HTML

The assets are images, scripts, styles, and perhaps some external media such as Flash movies or Java applets (remember those?). So, when it comes to download sizes, you should aim to have all the assets as lightweight as possible — advice which also extends to the page’s HTML content. Creating lean HTML code often means using better (semantic) markup, which also overlaps with the SEO (search engine optimization) efforts that are a necessary part of the site creation process. As most professional web developers know, a key characteristic of good markup is that it only describes the content, not the presentation of the page (no layout tables!). Any layout or presentational elements should be moved to CSS.

Here’s an example of a good approach to HTML markup for a navigation menu:

<ul id="menu">

<li><a href="home.html">Home</a></li>

<li><a href="about.html">About</a></li>

<li><a href="contact.html">Contact</a></li>

</ul>

This sort of markup should provide “hooks” to allow for the effective use of CSS and make the menu look however you want it to — whether that means adding fancy bullets, borders, or rollovers, or placing the menu items into a horizontal menu. The markup is minimal, which means there are fewer bytes to download; it’s semantic, meaning it describes the content (a navigation menu is a list of links); and finally, being minimal, it also gives you an SEO advantage: it’s generally agreed that search engines prefer a higher content-to-markup ratio in the pages that they index.

Once you’re sure your markup is lightweight and semantic, you should go through your assets and make sure they are also of minimal size. For example, check whether it’s possible to compress images more without losing too much quality, or to choose a different file format that gives you better compression. Tools such as PNGOUT and pngcrush are a good place to start.

Make Fewer HTTP Requests

Making fewer HTTP requests turns out to be the most important optimization technique, with the biggest impact. If your time is limited, and you can only complete one optimization task, pick this one. HTTP requests are generally the most “expensive” activity that the browser performs while displaying your page. Therefore, you should ensure that your page makes as few requests as possible.

How you can go about that, while maintaining the richness of your pages?

  • Combine scripts and style sheets: Do you have a few <script> tags in your head? Well, merge the .js files into one and save your visitors some round trips; then do the same with the CSS files.
  • Use image sprites: This technique allows you to combine several images into one and use CSS to show only the part of the image that’s needed. When you combine five or ten images into a single file, already you’re making a huge saving in the request/response overhead.
  • Avoid redirects: a redirect adds another client-server round trip, so instead of processing your page immediately after receiving the initial response, the browser will have to make another request and wait for the second response.
  • Avoid frames: if you use frames, the browser has to request at least three HTML pages, instead of just one — those of the frameset as well as each of the frames.

You’ve got the basics now. In summary, make your page and its assets smaller in size, and use fewer assets by combining them wherever you can. If you concentrate on this aspect of optimization only, you and your visitors will notice a significant improvement.

Now let’s explore some of the Yahoo! recommendations in more detail, and see what other optimizations can be made to improve performance.

Optimizing Assets

Use a Content Delivery Network

A Content Delivery Network (CDN) is a network of servers in different geographical locations. Each server has a copy of a site’s files. When a visitor to your site requests a file, the file is delivered from the nearest server (or the one that’s experiencing the lightest load at the time).

This setup can have a significant impact on your page’s overall performance, but unfortunately, using a CDN can be pricey. As such, it’s probably not something you’d do for a personal blog, but it may be useful when a client asks you to build a site that’s likely to experience high volumes of traffic. Some of the most widely known CDN providers are Akamai and Amazon, through its S3 service.

There are some non-profit CDNs in the market; check the CDN Wikipedia article to see if your project might qualify to use one of them. For example, one free non-profit peer-to-peer CDN is Coral CDN, which is extremely easy to integrate with your site. For this CDN, you take a URL and append “nyud.net” to the hostname. Here’s an example:

http://example.org/logo.png

becomes:

http://example.org.nyud.net/logo.png

Host Assets on Different Domains but Reduce DNS Lookups

After your visitor’s browser has downloaded the HTML for a page and figured out that a number of components are also needed, it begins downloading those components. Browsers restrict the number of simultaneous downloads that can take place; as per the HTTP/1.1 specification, the limit is two assets per domain.

Because this restriction exists on a per-domain basis, you can use several domains (or simply use subdomains) to host your assets, thus increasing the number of parallel downloads. Most shared hosts will allow you to create subdomains. Even if your host places a limit on the number of subdomains you can create (some restrict you to a maximum of five), it’s not that important, as you won’t need to utilize too many subdomains to see some noticeable performance improvements.

However, as Rule #9 states, you should also reduce the number of DNS lookups, because these can also be expensive. For every domain or subdomain that hosts a page asset, the browser will need to make a DNS lookup. So the more domains you have, the more your site will be slowed down by DNS lookups. Yahoo!’s research suggests that two to four domains is an optimal number, but you can decide for yourself what’s best for your site.

As a general guideline, I’d suggest you use one domain to host HTML pages and two other domains for your assets. Here’s an example:

  • www.sitepoint.com – hosts only HTML (and maybe content images)
  • i1.sitepoint.com – hosts JS, CSS, and some images
  • i2.sitepoint.com – hosts most of the site’s images

Different hosting providers will probably offer different interfaces for creating subdomains, and ideally they should provide you with an option to specify the directory that holds the files for the subdomain. For example, if your canonical domain is www.sitepoint.com, and it points to /home/sitepoint/htdocs, ideally you should be able to create the subdomain i1.sitepoint.com (either via an administration control panel or by creating a symbolic link in the file system) and point it to the same folder, /home/sitepoint/htdocs. This way, you can keep all files in the same location, just as they are in your development environment, but reference them using a subdomain.

However, some hosts may prevent you from creating subdomains, or may restrict your ability to point to particular locations on the file system. In such cases, your only real options is to physically copy the assets to the new location. Don’t be tempted to create some kind of redirect in this case — it will only make things worse, as it creates two requests for each image.

If your hosting provider doesn’t allow subdomains at all, you always have the option of buying more domains and using them purely to host assets — after all, that’s what a lot of big sites do. Yahoo! uses the domain yimg.com, Amazon has images-amazon.com, and SitePoint has sitepointstatic.com. If you own several sites, or manage the hosting of your client’s sites, you might consider buying two domains, such as yourdomain-i1.com and yourdomain-i2.com, and using them to host the components for all the sites you maintain.

Place Assets on a Cookie-free Domain

If you set a lot of cookies, the request headers for your pages will increase in size, since those cookies are sent with each request. Additionally, your assets probably don’t use the cookies, so all of this information could be repeatedly sent to the client for no reason. Sometimes, those headers m

ay even be bigger than the size of the asset requested — these are extreme cases of course, but it happens. Consider downloading those small icons or smilies that are less than half a kB, and requesting them with 1kB worth of HTTP headers.

If you use subdomains to host your assets, you need to make sure that the cookies you set are for your canonical domain name (e.g. www.example.org) and not for the top-level domain name (e.g. example.org). This way, your asset subdomains will be cookie-free. If you’re attempting to improve the performance of an existing site, and you’ve already set your cookies on the top-level domain, you could consider the option of hosting assets on new domains, rather than subdomains.

Split the Assets Among Domains

It’s completely up to you which assets you decide to host on i1.example.org and which you decide to host on i2.example.org — there’s no clear directive on this point. Just make sure you don’t randomize the domain on each request, as this will cause the same assets to be downloaded twice — once from i1 and once from i2.

You could aim to split your assets evenly by file size, or by some other criterion that makes sense for your pages. You may also choose to put all content images (those that are included in your HTML with <img /> tags) on i1 and all layout images (those referenced by CSS‘s background-image:url()) on i2, although in some cases this solution may not be optimal. In such cases, the browser will download and process the CSS files and then, depending on which rules need to be applied, will selectively download only images that are needed by the style sheet. The result is that the images referenced by CSS may not download immediately, so the load on your asset servers may not be balanced.

The best way to decide on splitting assets is by experimentation; you can use Firebug‘s Net panel to monitor the sequence in which assets download, then decide how you should spread components across domains in order to speed up the download process.

Configure DNS Lookups on Forums and Blogs

Since you should aim to have no more than four DNS lookups per page, it may be tricky to integrate third-party content such as Flickr images or ads that are hosted on a third-party server. Also, hotlinking images (by placing on your page an <img /> tag whose src attribute points to a file on another person’s server) not only steals bandwidth from the other site, but also harms your own page’s performance, causing an extra DNS lookup.

If your site contains user-generated content (as do forums, for example), you can’t easily prevent multiple DNS lookups, since users could potentially post images located anywhere on the Web. You could write a script that copies each image from a user’s post to your server, but that approach can get fairly complicated.

Aim for the low-hanging fruit. For example, in the phpBB forum software, you can configure whether users need to hotlink their avatar images or upload them to your server. In this case, uploaded avatars will result in better performance for your site.

Use the Expires Header

For best performance, your static assets should be exactly that: static. This means that there should be no dynamically generated scripts or styles, or <img> tags pointing to scripts that generate dynamic images. If you had such a need — for example, you wanted to generate a graphic containing your visitor’s username — the dynamic generation could be taken “offline” and the result cached as a static image. In this example, you could generate the image once, when the member signs up. You could then store the image on the file system, and write the path to the image in your database. An alternative approach might involve scheduling an automated process (a cron job, in UNIX) that generates dynamic components and saves them as static files.

Having assets that are entirely static allows you to set the Expires header for those files to a date that is far in the future, so that when an asset is downloaded once, it’s cached by the browser and never requested again (or at least not for a very long time, as we’ll see in a moment).

Setting the Expires header in Apache is easy: add an .htaccess file that contains the following directives to the root folder of your i1 and i2 subdomains:

ExpiresActive On

ExpiresDefault "modification plus 10 years"

The first of these directives enables the generation of the Expires header. The second sets the expiration date to 10 years after the file’s modification date, which translates to 10 years after you copied the file to the server. You could also use the setting “access plus 10 years”, which will expire the file 10 years after the user requests the file for the first time.

If you want, you can even set an expiration date per file type:

ExpiresActive On

ExpiresByType application/x-javascript "modification plus 2 years"

ExpiresByType text/css "modification plus 5 years"

For more information, check the Apache documentation on mod_expires.

Name Assets

The problem with the technique that we just looked at (setting the Expires

header to a date that’s far into the future) occurs when you want to modify an asset on that page, such as an image. If you just upload the changed image to your web server, new visitors will receive the updated image, but repeat visitors won’t. They’ll see the old cached version, since you’ve already instructed their browser never to ask for this image again.

The solution is to modify the asset’s name — but it comes with some maintenance hurdles. For example, if you have a few CSS definitions pointing to img.png, and you modify the image and rename it to img2.png, you’ll have to locate all the points in your style sheets at which the file has been referenced, and update those as well. For bigger projects, you might consider writing a tool to do this for you automatically.

You’ll need to come up with a naming convention to use when naming your assets. For example, you might:

  • Append an epoch timestamp to the file name, e.g. img_1185403733.png.
  • Use the version number from your source control system (cvs or svn for example), e.g. img_1.1.png.
  • Manually increment a number in the file name (e.g. when you see a file named img1.png, simply save the modified image as img2.png).

There’s no one right answer here — your decision will be depend on your personal preference, the specifics of your pages, the size of the project and your team, and so on.

If you use CVS, here’s a little PHP function that can help you extract the version from a file stored in CVS:

function getVersion($file) {

$cmd = ‘cvs log -h %s';

$cmd = sprintf($cmd, $file);

exec($cmd, $res);

$version = trim(str_replace(‘head: ‘, ”, $res[3]));

return $version;

}

// example use

$file = ‘img.png';

$new_file = ‘img_’ . getVersion($file) . ‘.png';

Serve gzipped Content

Most modern browsers understand gzipped (compressed) content, so a well-performing page should aim to serve all of its content compressed. Since most images, swf files and other media files are already compressed, you don’t need to worry about compressing them.

You do, however, need to take care of serving compressed HTML, CSS, client-side scripts, and any other type of text content. If you make XMLHttpRequests to services that return XML (or JSON, or plain text), make sure your server gzips this content as well.

If you open the Net panel in Firebug (or use LiveHTTPHeaders or some other packet sniffer), you can verify that the content is compressed by looking for a Content-Encoding header in the response, as shown in the following example:

Example request:

GET /2.2.2/build/utilities/utilities.js HTTP/1.1

Host: yui.yahooapis.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

Accept-Encoding: gzip,deflate

Example response:

HTTP/1.x 200 OK

Last-Modified: Wed, 18 Apr 2007 17:36:33 GMT

Vary: Accept-Encoding

Content-Type: application/x-javascript

Content-Encoding: gzip

Cache-Control: max-age=306470616

Expires: Sun, 16 Apr 2017 00:01:52 GMT

Date: Mon, 30 Jul 2007 21:18:16 GMT

Content-Length: 22657

Connection: keep-alive

In this request, the browser informed the server that it understands gzip and deflate encodings (Accept-Encoding: gzip,deflate) and the server responded with gzip-encoded content (Content-Encoding: gzip).

There’s one gotcha when it comes to serving gzipped content: you must make sure that proxies do not get in your way. If an ISP’s proxy caches your gzipped content and serves it to all of its customers, chances are that someone with a browser that doesn’t support compression will receive your compressed content.

To avoid this you can use the Vary: Accept-Encoding response header to tell the proxy to cache this response only for clients that send the same Accept-Encoding request header. In the example above, the browser said it supports gzip and deflate, and the server responded with some extra information for any proxy between the server and client, saying that gzip-encoded content is okay for any client that sends the same Accept-Encoding content.

There is one additional problem here: some browsers (IE 5.5, IE 6 SP 1, for instance) claim they support gzip, but can actually experience problems reading it (as described on the Microsoft downloads site, and the support site). If you care about people using these browsers (they usually account for less than 1% of a site’s visitors) you can use a different header — Cache-Control: Private — which eliminates proxy caching completely. Another way to prevent proxy caching is to use the header Vary: *.

To gzip or to Deflate?

If you’re confused by the two Accept-Encoding values that browsers send, think of deflate as being just another method for encoding content that’s less popular among browsers. It’s also less efficient, so gzip is preferred.

Make Sure you Send gzipped Content

Okay, now let’s see what you can do to start serving gzipped content in accordance with what your host allows.

Option 1: mod_gzip for Apache Versions Earlier than 2

If you’re using Apache 1.2 and 1.3, the mod_gzip module is available. To verify the Apache version, you can check Firebug’s Net panel and look for the Server response header of any request. If you can’t see it, check you provider’s documentation or create a simple PHP script to echo this information to the browser, like so:

<?php echo apache_get_version(); ?>

In the Server header signature, you might also be able to see the mod_gzip version, if it’s installed. It might look like s

omething like this:

Server: Apache/1.3.37 (Unix) mod_gzip/1.3.26.1a.....

Okay, so we’ve established that we want to compress all text content, PHP script output, static HTML pages, JavaScripts and style sheets before sending them to the browser. To implement this with mod_gzip, create in the root directory of your site an .htaccess file that includes the following:

mod_gzip_on Yes

mod_gzip_item_include mime ^application/x-javascript$

mod_gzip_item_include mime ^application/json$

mod_gzip_item_include mime ^text/.*$

mod_gzip_item_include file .html$

mod_gzip_item_include file .php$

mod_gzip_item_include file .js$

mod_gzip_item_include file .css$

mod_gzip_item_include file .txt$

mod_gzip_item_include file .xml$

mod_gzip_item_include file .json$

Header append Vary Accept-Encoding

The first line enables mod_gzip. The next three lines set compression based on MIME-type. The next section does the same thing, but on the basis of file extension. The last line sets the Vary header to include the Accept-Encoding value.

If you want to send the Vary: * header, use:

Header set Vary *

Note that some hosting providers will not allow you to use the Header directive. If this is the case, hopefully you should be able to substitute the last line with this one:

mod_gzip_send_vary On

This will also set the Vary header to Accept-Encoding.

Be aware that there might be a minimum size condition on gzip, so if your files are too small (less than 1kb, for example), they might not be gzipped even though you’ve configured everything correctly. If this problem occurs, your host has decided that the gzipping process overhead is unnecessary for very small files.

Option 2: mod_deflate for Apache 2.0

If your host runs Apache 2 you can use mod_deflate. Despite its name, mod_deflate also uses gzip compression. To configure mod_deflate, add the following directives to your .htaccess file:

AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/json

Header append Vary Accept-Encoding

Option 3: php.ini

Ideally we’d like Apache to handle the gzipping of content, but unfortunately some hosting providers might not allow it. If your hosting provider is one of these, it might allow you to use custom php.ini files. If you place a php.ini file in a directory, it overwrites PHP configuration settings for this directory and its subdirectories.

If you can’t use Apache’s mod_gzip or mod_deflate modules, you might still be able to compress your content using PHP. In order for this solution to work, you’ll have to configure your web server so that all static HTML, JavaScript and CSS files are processed by PHP. This means more overhead for the server, but depending on your host, it might be your only option.

Add the following directives in your .htaccess file:

AddHandler application/x-httpd-php .css

AddHandler application/x-httpd-php .html

AddHandler application/x-httpd-php .js

This will ensure that PHP will process these (otherwise static) files. If it doesn’t work, you can try renaming the files to have a .php extension (like example.js.php, and so on) to achieve the same result.

Now create a php.ini file in the same directory with the following content:

[PHP]

zlib.output_compression = On

zlib.output_compression_level = 6

auto_prepend_file = "pre.php"

short_open_tag = 0

This enables compression and sets the compression level to 6. Values for the compression level range from 0 to 9, where 9 is the best (and slowest) compression. The last line sets up a file called pre.php to be executed at the beginning of every script, as if you had typed <?php include "pre.php"; ?> at the top of every script. You’ll need this file in order to set Content-Type headers, because some browsers might not like it when you send a CSS file that has, for example, a text/html content type header.

The short_open_tag setting is there to disable PHP short tags (<? ... ?>, as compared to <?php ... ?>). This is important because PHP will attempt to treat the <?xml tag in your HTML as PHP code.

Finally, create the file pre.php with the following content:

<?php

$path = pathinfo($_SERVER[‘SCRIPT_NAME’]);

if ($path[‘extension’] == ‘css’) {

header(‘Content-type: text/css’);

}

if ($path[‘extension’] == ‘js’) {

header(‘Content-type: application/x-javascript’);

}

?>

This script will be executed before every file that has a .php, .html, .js or .css file extension. For HTML and PHP files, the default Content-Type text/html is okay, but for JavaScript and CSS files, we change it using PHP’s header function.

Option 3 (Variant 2): PHP Settings in .htaccess

If your host allows you to set PHP settings in your .htaccess file, then you no longer need to use php.ini file to configure your compression settings. Instead, set the PHP setting in .htaccess using php_value (and php_flag
).

Looking at the modified example from above, we would have the same pre.php file, no php.ini file, and a modified .htaccess that contained the following directives:

AddHandler application/x-httpd-php .css

AddHandler application/x-httpd-php .html

AddHandler application/x-httpd-php .js

php_flag zlib.output_compression on

php_value zlib.output_compression_level 6

php_value auto_prepend_file "pre.php"

php_flag short_open_tag off

Option 4: In-script Compression

If your hosting provider doesn’t allow you to use php_value in your .htaccess file, nor do they allow you to use a custom php.ini file, your last resort is to modify the scripts to manually include the common pre.php file that will take care of the compression. This is the least-preferred option, but sometimes you may have no other alternative.

If this is your only option, you’ll either be using an .htaccess file that contains the directives outlined in Option 3 above, or you’ll have had to rename every .js and .css file (and .xml, .html, etc.) to have a .php extension. At the top of every file, add <?php include "pre.php"; ?> and create a file called pre.php that contains the following content:

<?php

ob_start("ob_gzhandler");

$path = pathinfo($_SERVER[‘SCRIPT_NAME’]);

if ($path[‘extension’] == ‘css’) {

header(‘Content-type: text/css’);

}

if ($path[‘extension’] == ‘js’) {

header(‘Content-type: application/x-javascript’);

}

?>

As I indicated, this is the least favorable option of all — you should try Option 1 or 2 first, and if they don’t work, consider Option 3 or 4, or a combination of both, depending on what your host allows.

Once you’ve established the degree of freedom your host permits, you can use the technique that you’ve employed to compress your static files to implement all of your Apache-related settings. For example, earlier I showed you how to set the Expires header. Well, guess what? Some hosts won’t allow it. If you find yourself in this situation, you can use PHP’s header function to set the Expires header from your PHP script.

To do so, you might add to your pre.php file something like this:

<?php

header("Expires: Mon, 25 Dec 2017 05:00:00 GMT");

?>

Disable ETags

Compared to the potential hassles that can be encountered when implementing the rule above, the application of this rule is very easy. You just need to add the following to your .htaccess file:

FileETags none

Note that this rule applies to sites that are in a server farm. If you’re using a shared host, you could skip this step, but I recommend that you do it regardless because:

  • Hosts change their machines for internal purposes.
  • You may change hosts.
  • It’s so simple.

Use CSS Sprites

Using a technique known as CSS sprites, you can combine several images into a single image, then use the CSS background-position property to show only the image you need. The technique is not intended for use with content images (those that appear in the HTML in <img /> tags, such as photos in a photo gallery), but is intended for use with ornamental and decorative images. These images will not affect the fundamental usability of the page, and are usually referenced from a style sheet in order to keep the HTML lean (Rule #0).

Let’s look at an example. We’ll take two images. The first is help.png; the second is rss.png. From these, we’ll create a third image, sprite.png, which contains both images.

Combining two image files into a single image (click to view image)

The resulting image is often smaller in size than the sum of the two files’ sizes, because the overhead associated with an image file is included only once. To display the first image, we’d use the following CSS rule:

#help {

background-image: url(sprite.png);

background-position: -8px -8px;

width: 16px;

height: 16px;

}

To display the second image, we’d use the following rule:

#rss {

background-image: url(sprite.png);

background-position: -8px -40px;

width: 16px;

height: 16px;

}

At first glance, this technique might look a bit strange, but it’s really useful for decreasing the number of HTTP requests. The more images you combine this way, the better, because you’re cutting the request overhead dramatically. For an example of this technique in use “in the wild”, check out this image, used on Yahoo!’s homepage, or this one from Google’s.

In order to produce sprite images quickly, without having to calculate pixel coordinates, feel free to use the CSS Sprites Generator tool that I’ve developed. And for more information about CSS sprites, be sure to read Dave Shea’s article, titled CSS Sprites: Image Slicing’s Kiss of Death.

Use Post-load Pre-loading and Inline Assets

If you’re a responsible web developer, you’re probably already adhering to the separation of concerns and using HTML for your content, CSS for presentation and JavaScript for behavior. While these distinct parts of a page should be kept in separate files at all times, for performance reasons you might sometimes consider breaking the rule on your index (home) page. The homepage should always be the fastest page on your site — many first-time visitors may leave your site, no matter what content it contains, if they find the homepage slow to load.

When a visitor arrives at your homepage with an empty cache, the fastest way to deliver the page is to have only one request and no separate components. This means having scripts and styles inline (gasp)! It’s actually possible to have inline images as well (although it’s not supported in IE) but that’s probably taking things too far. Apart from being semantically incorrect, using inline scripts and styles prevents those components from being cached, so a good strategy will be to load components in the background after the home page has loaded — a technique with the slightly confusing name of post-load preloading. Let’s see an example.

Let’s suppose that the file containing your homepage is named home.html, that numerous other HTML files containing content are scattered throughout your site, and that all of these content pages use a JavaScript file, mystuff.js, of which only a small part is needed by the homepage.

Your strategy might be to take the part of the JavaScript that’s used by the homepage out of mystuff.js and place it inline in home.html. Then, once home.html has completed loading, make a behind-the-scenes request to pre-load mystuff.js. This way, when the user hits one of your content pages, the JavaScript has already been delivered to the browser and cached.

Once again, this technique is used by some of the big boys: both Google and Yahoo! have inline scripts and styles on their homepages, and they also make use of post-load preloading. If you visit Google’s homepage, it loads some HTML and one single image — the logo. Then, once the home page has finished loading, there is a request to get the sprite image, which is not actually needed until the second page loads — the one displaying the search results.

The Yahoo search page performs conditional pre-loading — this page doesn’t automatically load additional assets, but waits for the user to start typing in the search box. Once you’ve begun typing, it’s almost guaranteed that you’ll submit a search query. And when you do, you’ll land on a search results page that contains some components that have already been cached for you.

Preloading an image can be done with a simple line of JavaScript:

new Image().src='image.png';

For preloading JavaScript files, use the JavaScript include_DOM technique and create a new <script> tag, like so:

var js = document.createElement('script');

js.src = 'mysftuff.js';

document.getElementsByTagName('head')[0].appendChild(js);

Here’s the CSS version:

var css = document.createElement('link');

css.href = 'mystyle.css';

css.rel = 'stylesheet';

document.getElementsByTagName('head')[0].appendChild(css);

In the first example, the image is requested but never used, so it doesn’t affect the current page. In the second example, the script is added to the page, so as well as being downloaded, it will be parsed and executed. The same goes for the CSS — it, too, will be applied to the page. If this is undesirable, you can still pre-load the assets using XMLHttpRequest.

JavaScript Optimizations

Before diving into the JavaScript code and micro-optimizing every function and every loop, let’s first look at what big-picture items we can tackle easily that might have a significant impact on a site’s performance. Here are some guidelines for improving the impact that JavaScript files have on your site’s performance:

  1. Merge .js files.
  2. Minify or obfuscate scripts.
  3. Place scripts at the bottom of the page.
  4. Remove duplicates.

Merge .js Files

As per the basic rules, you should aim for your JavaScripts to make as few requests as possible; ideally, this also means that you should have only one .js file. This task is as simple as taking all .js script files and placing them into a single file.

While a single-file approach is recommended in most cases, sometimes you may derive some benefit from having two scripts — one for the functionality that’s needed as soon as the page loads, and another for the functionality that can wait for the page to load first. Another situation in which two files might be desirable is when your site makes use of a piece of functionality across multiple pages — the shared scripts could be stored in one file (and thus cached from page to page), and the scripts specific to that one page could be stored in the second file.

Minify or Obfuscate Scripts

Now that you’ve merged your scripts, you can go ahead and minify or obfuscate them. Minifying means removing everything that’s not necessary — such as comments and whitespace. Obfuscating goes one step further and involves renaming and rearranging functions and variables so that their names are shorter, making the script very difficult to read. Obfuscation is often used as a way of keeping JavaScript source a secret, although if your script is available on the Web, it can never be 100% secret. Read more about minification and obfuscation in Douglas Crockford’s helpful article on the topic.

In general, if you gzip the JavaScript, you’ll already have made a huge gain in file size, and you’ll only obtain a small additional benefit by minifying and/or obfuscating the script. On average, gzipping alone can result in savings of 75-80%, while gzipping and minifying can give you savings of 80-90%. Also, when you’re changing your code to minify or obfuscate, there’s a risk that you may introduce bugs. If you’re not overly worried about someone stealing your code, you can probably forget obfuscation and just merge and minify, or even just merge your scripts only (but always gzip them!).

An excellent tool for JavaScript minification is JSMin and it also has a PHP port, among others. One obfuscation tool is Packer — a free online tool that, incidentally, is used by jQuery.

Changing your code in order to merge and minify should become an extra, separate step in the process of developing your s

ite. During development, you should use as many .js files as you see fit, and then when the site is ready to go live, substitute your “normal” scripts with the merged and minified version. You could even develop a tool to do this for you. Below, I’ve included an example of a small utility that does just this. It’s a command-line script that uses the PHP port of JSMin:

<?php

include 'jsmin.php';

array_shift($argv);

foreach ($argv AS $file) {

echo ‘/* ‘, $file, ‘ */';

echo JSMin::minify(file_get_contents($file)), “n”;

}

?>

Really simple, isn’t it? You can save it as compress.php and run it as follows:

$ php compress.php source1.js source2.js source3.js > result.js

This will combine and minify the files source1.js, source2.js, and source3.js into one file, called result.js.

The script above is useful when you merge and minify as a step in the site deployment process. Another, lazier option is to do the same on the fly — check out Ed Eliot’s blog post, and this blog post by SitePoint’s Paul Annesley for some ideas.

Many third-party JavaScript libraries are provided in their uncompressed form as well as in a minified version. You can therefore download and use the minified versions provided by the library’s creator, and then only worry about your own scripts. Something to keep in mind is the licensing of any third-party library that you use. Even though you might have combined and minified all of your scripts, you should still retain the copyright notices of each library alongside the code.

Place Scripts at the Bottom of the Page

The third rule of thumb to follow regarding JavaScript optimization is that the script should be placed at the bottom of the page, as close to the ending </body> tag as possible. The reason? Well, due to the nature of the scripts (they could potentially change anything on a page), browsers block all downloads when they encounters a <script> tag. So until a script is downloaded and parsed, no other downloads will be initiated.

Placing the script at the bottom is a way to avoid this negative blocking effect. Another reason to have as few <script> tags as possible is that the browser initiates its JavaScript parsing engine for every script it encounters. This can be expensive, and therefore parsing should ideally only occur once per page.

Remove Duplicates

Another guideline regarding JavaScript is to avoid including the same script twice. It may sound like strange advice (why would you ever do this?) but it happens: if, for example, a large site used multiple server-side includes that included JavaScript files, it’s conceivable that two of these might double up. The duplicate script would cause the browser’s parsing engine to be started twice and possibly (in some IE versions) even request the file for the second time. Duplicate scripts might also be an issue when you’re using third party libraries. Let’s suppose you had a carousel widget and a photo gallery widget that you downloaded from different sites, and they both used jQuery. In this case you’d want to make sure that you didn’t include jQuery twice by mistake. Also, if you use YUI, make sure you don’t include a library twice by including, for example, the DOM utility (dom-min.js), the Event utility (event-min.js) and the utilities.js library, which contains both DOM and Event.

CSS Optimizations

Merge and Minify

For your CSS files you can follow the guidelines we discussed for JavaScripts: minify and merge all style sheets into a single file to minimize download size and the number of HTTP requests taking place. Merging all files into one is a trivial task, but the job of minification may be a bit harder, especially if you’re using CSS hacks to target specific browsers — since some hacks exploit parsing bugs in the browsers, they might also trick your minifier utility.

You may decide not to go through the hassle of minifying style sheets (and the associated re-testing after minification). After all, if you decide to serve the merged and gzipped style sheet, that’s already a pretty good optimization.

If you do decide to minify CSS, apart from the option of minifying manually (simply removing comments and whitespace), you can use some of the available tools, such as CSSTidy, PEAR‘s HTML_CSS library (http://pear.php.net/package/HTML_CSS/), or SitePoint’s own Dust-me Selectors Firefox plugin.

Place Styles at the Top of the Page

Your single, gzipped (and optionally minified) style sheet is best placed at the beginning of the HTML file, in the <head> section — which is where you’d usually put it anyway. The reason is that most browsers (Opera is an exception) won’t render anything on the page until the all the style sheets are duly downloaded and parsed. Additionally, none of the images referenced from the CSS will be downloaded unless the CSS parsing is complete. So it’s better to include the CSS as early on the page as possible.

You might think about distributing images across different domains, though. Images linked from the CSS won’t be downloaded until later, so in the meantime, your page can use the available download window to request content images from the domain that hosts the CSS images and is temporarily “idle”.

Ban Expressions

IE allows JavaScript expressions in CSS, like this one:

#content {

left: expression(document.body.offsetWidth)

}

You should avoid JavaScript expressions for a number of reasons. First of all, they’re not supported by all browsers. They also harm the “separation of concerns”. And, when it comes to performance, expressions are bad because they’re recalculated every time the page is rendered or resized, or simply when you roll your mouse over the page. There are ways to make expressions less expensive — you can cache values after they’re initially calculated, but you’re probably better off simply to avoid them.

Tools for Performance Optimization

A number of tools can help you in your performance optimization quest. Most importantly, you’d want to monitor what’s happening when the page is loaded, so that you can make informed decisions. Try these utilities:

Summary

Whew! If you’ve made it this far, you now know quite a lot about how to approach a site optimization project (and more importantly, how to build your next web site with performance in mind). Remember the general rule of thumb that, when it comes to optimization, you should concentrate on the items with the biggest impact, as opposed to “micro-optimizing”.

You may choose not to implement all the recommendations discussed above, but you can still make quite a difference by focusing on the really low-hanging fruit, such as:

  • making fewer HTTP requests by combining components — JavaScript files, style sheets and images (by using CSS Sprites)
  • serving all textual content, including HTML, scripts, styles, XML, JSON, and plain text, in a gzipped format
  • minifying and placing scripts at the bottom, and style sheets at the top of your files
  • using separate cookie-free domains for your components

Good luck with your optimization efforts — it’s very rewarding when you see the results!

Web Site Designing and publishing

June 22, 2008 · 1 Comment
Filed under: Creative Website Design, Featured, Hit Counters, SEO 

Free Hit Counters

  1. http://my.statcounter.com
  2. http://easyhitcounters.com
  3. http://www.statssheet.com
  4. http://www.neoworx.net

Free Maps on Your Site

  1. http://clustrmaps.com
  2. http://www.ip2map.com
  3. http://www.neoworx.net

Free Site Stats Reports

  1. http://my.statcounter.com/
  2. http://www.statssheet.com

Track the location of visitor

  1. http://www.ip2phrase.com/
  2. http://my.statcounter.com/
  3. http://www.neoworx.net/

Web Master Tools

  1. https://www.google.com/webmasters

Live Cricket On your Site

  1. http://www.vcricket.com

Free Web Site Hosting

  1. www.blogspot.com
  2. www.googlepages.com
  3. www.50megs.com
  4. www.geocities.com
  5. www.netfirms.com