Don’t use client side includes!

Builder.com’s Using Client Side Includes instead of Server Side Includes makes the case for replacing server-side techniques for including common page components with alternatives powered by Javascript. My advice: stay well clear. While Javascript includes may reduce the load on your server slightly and may even increase page loading times due to additional client-side caching, the cons far outweigh the pros:

  • Javascript is a serious accessibility red flag: to meet accessibility requirements your content needs to be accessible for users and devices which lack Javascript support.
  • Search engines can’t see content that is added with Javascript. If you hide your links in Javascript search engine spiders will be unable to even crawl your site.
  • Javascript is cached aggressively by many browsers. This may help performance, but it means that changes you make to your includes may not show up unless visitors force-refresh their browsers. You can’t expect them to do that very often, if ever.
  • The performance hit of enabling SSIs is usually greatly over-stated. Modern web servers are usually hugely powerful machines. Many sites dynamically generate every page using technologies such as PHP or Perl, which carry far higher overheads than simple SSIs.

If your host doesn’t support some form of server side include, you should move to another host. The hosting market is saturated these days and good quality hosting with all the frills for a moderately trafficed site shouldn’t set you back more than five or ten dollars a month. Note that that’s assuming you go with an open source platform; proprietary hosting platforms can cost quite a bit more.

The only case when Javascript includes might make sense is if you are distributing a site on a CD where a dynamic serving platform is not available, but even then a better solution would be to generate the static HTML files on the CD using a template and a simple scripting language.

My golden rule for Javascript is that it should not result in inacccessible content for non-Javascript browsers. If it enhances the user experience for those with Javascript then fine, just as long as it doesn’t result in a non-functioning site for everyone else.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.delyrical.com davidjmedlock

    Excellent advice, Simon. It’s an interesting concept, but from my point of view, all together useless. You’re very right about web servers being able to very easily handle includes. The performance difference will likely go unnoticed by the vast majority of users, no matter what server side language you employ.

  • http://www.ryanguill.com Rynoguill

    here here, i completely agree. i actually try to do everything i possibly can without js

  • mr_jeep

    Yep, I agree too. Javascript should never be part of the functionality. I mean a website sould work without javascript,

  • Jeremy Dunck

    Hey, I like JS includes quite a lot. I mean, who wants scary spiders crawling about your site internals?

    And who needs to be accessible to non-JS browsers? That 20% of business is -so- over-rated.

    And who wants to deal with that scary gzip response encoding? People would have to get a real web server to deal with that mess.

    …But seriously, you -could- send back a non-JS response to search engine bots.

    I tried to talk my coworkers into using, you know, HTTP to handle bandwidth issues, but my work’s site sends back non-JS includes, but checks to see if JS is enabled and sends back that fact as a parameter. The server then starts sending JS includes to a browser that can handle it.

    Much more complicated that gzipping, though.

  • http://www.xhtmlcoder.com/ xhtmlcoder

    I think they must be slightly crazy to use Client-Side over Server-Side Inclusion for standard headers and footers.

  • http://www.igeek.info asp_funda

    Ditto!!
    JavaScript includes are too bothersome & most of the times result in complications that are not worth bothering on.

  • http://ajdevies.home.att.net ajdevies

    “And who needs to be accessible to non-JS browsers? That 20% of business is -so- over-rated.”
    Posted by: Jeremy Dunck @ 9:48 PM MDT

    That 20% currently represents a significant source of buying power which will continue to grow as baby-boomers age, lose eye-sight, manual dexterity, etc. Mr. Dunck is out-of-touch with societal and statistical trends.

    As a person with multiple disabilities, I personally find this level of insensitivity offensive and inexcusable. I dare Mr. Dunck to spend one day of his life as I spend, and will continue to spend, the rest of my life.

    There is also a little thing called “discrimination” against persons with disabilities. It is codified in the United States under the Americans with Disabilities Act of 1990. Look it up at http://www.ada.gov.

    Accessibility is not about sheer numbers, it is about doing the “right” thing on a voluntary basis in the open market in order to gain/maintain marketshare and goodwill.

    Yes, it costs a little more and takes more time to implement, but until you really, really need it, you cannot and will not understand its true value.

  • Not too serious

    He was kidding about the 20%.

  • http://simon.incutio.com/ Skunk

    ajdevies, he was being saracastic throughout his whole comment. I’m sure no offense was meant – I’ve met Jeremy and he is a huge advocate of best practises in web development, which includes accessibility.

  • Jimmy Cerra

    What about the origional CSI (ha, cool abbr): external entities? Sure, most browsers and parsers don’t support it; however, some do – like IE. I think they would be cool while writing for a site, then using a normalizer to “put it” in entites.

  • Jimmy Cerra

    What about the “origional client-side include: external entities, which are defined in the internal subset of the doctype declaration. Ya, most browsers don’t support them – but I remember IE parsing and including them! I think they could be a real time saver when writing for a web site (a normalizer could be used to replace all entities with their equivalents).

  • Jeremy Dunck

    ajdevies,
    Sorry to have caused you distress. I was, as Simon points out, trying to be sarcastic.
    I was parodying several of the reasons for using client-side includes that I have heard, none of which make much sense.
    I actually think the ADA goes a bit too far, as you simply can not make affordances for all possible limitations people may have.
    But there are many places that I think corporations get far too much slack, and I’m happy that the Constitution is still upheld in some fashion. I think the ADA does a lot of good.
    You’re quite right that I can’t properly appreciate the difficulties; but I’m not actually that jerk you read.

    -Jeremy

  • charlie

    JavaScript is a popular general-purpose scripting language used to put energy and pizzaz into otherwise dead Web pages by allowing a static page to interact with users and respond to events that occur on the page.

  • Thierry

    Spiders tend to take every thing that is readable on a page. I’d say CSI can be useful when you want a particular part of your page content (accessory tools, my accounts links, prices, navigation) NOT to be indexed by SE spiders/robots.

    Unless some other trick is pulled out of the hat!?

    Just a thought!
    http://www.8P-Design.com

  • cyndi

    Any thoughts about using CSI on an Intranet?

  • Levi Senft

    We use Client Side Includes for mock-ups to show clients interaction on user interface projects or how a design is going to work in a browser. Then when we go into production we replace the CSIs with the final code, SSIs or a templating engine. If you want to check our CSI engine out I posted it here:

    jsInclude