Take the 2-minute tour ×

What things should a programmer implementing the technical details of a web application consider before making the site public? If Jeff Atwood can forget about HttpOnly cookies, sitemaps, and cross-site request forgeries all in the same site, what important thing could I be forgetting as well?

I'm thinking about this from a web developer's perspective, such that someone else is creating the actual design and content for the site. So while usability and content may be more important than the platform, you the programmer have little say in that. What you do need to worry about is that your implementation of the platform is stable, performs well, is secure, and meets any other business goals (like not cost too much, take too long to build, and rank as well with Google as the content supports).

Think of this from the perspective of a developer who's done some work for intranet-type applications in a fairly trusted environment, and is about to have his first shot and putting out a potentially popular site for the entire big bad world wide web.

Also, I'm looking for something more specific than just a vague "web standards" response. I mean, HTML, JavaScript, and CSS over HTTP are pretty much a given, especially when I've already specified that you're a professional web developer. So going beyond that, Which standards? In what circumstances, and why? Provide a link to the standard's specification.


locked by Yannis Rizos Jun 21 '13 at 19:48

This question's answer is a collaborative effort: if you see something that can be improved, just edit to improve it! No additional answers can be added here

This lock is best applied to a question that has a single CW answer that covers all the points. At the moment that doesn't apply to this question, so if people could take one of the other (deleted) answers and edit it into the accepted answer, that would be great. –  ChrisF Jun 21 '13 at 19:34
comments disabled on deleted / locked posts

1 Answer

up vote 2146 down vote accepted

The idea here is that most of us should already know most of what is on this list. But there just might be one or two items you haven't really looked into before, don't fully understand, or maybe never even heard of.

Interface and User Experience

  • Be aware that browsers implement standards inconsistently and make sure your site works reasonably well across all major browsers. At a minimum test against a recent Gecko engine (Firefox), a WebKit engine (Safari and some mobile browsers), Chrome, your supported IE browsers (take advantage of the Application Compatibility VPC Images), and Opera. Also consider how browsers render your site in different operating systems.
  • Staging: How to deploy updates without affecting your users. Have one or more test or staging environments available to implement changes to architecture, code or sweeping content and ensure that they can be deployed in a controlled way without breaking anything. Have an automated way of then deploying approved changes to the live site. This is most effectively implemented in conjunction with the use of a version control system (CVS, Subversion, etc.) and an automated build mechanism (Ant, NAnt, etc.).
  • Don't display unfriendly errors directly to the user.
  • Don't put users' email addresses in plain text as they will get spammed to death.
  • Build well-considered limits into your site - This also belongs under Security.
  • Learn how to do progressive enhancement.
  • Don't forget to take accessibility into account. It's always a good idea and in certain circumstances it's a legal requirement. WAI-ARIA and WCAG 2 are good resources in this area.
  • Don't make me think



  • Optimize images - don't use a 20 KB image for a repeating background.
  • Take a look at the Yahoo Exceptional Performance site, lots of great guidelines, including improving front-end performance and their YSlow tool (requires Firefox, Safari, Chrome or Opera). Also, Google page speed (use with browser extension) is another tool for performance profiling, and it optimizes your images too.
  • Use CSS Image Sprites for small related images like toolbars (see the "minimize HTTP requests" point)
  • Busy web sites should consider splitting components across domains. Specifically...
  • Static content (i.e. images, CSS, JavaScript, and generally content that doesn't need access to cookies) should go in a separate domain that does not use cookies, because all cookies for a domain and its subdomains are sent with every request to the domain and its subdomains. One good option here is to use a Content Delivery Network (CDN).
  • Utilize Google Closure Compiler for JavaScript and other minification tools.

SEO (Search Engine Optimization)

  • Use "search engine friendly" URLs, i.e. use example.com/pages/45-article-title instead of example.com/index.php?page=45
  • Don't use links that say "click here". You're wasting an SEO opportunity and it makes things harder for people with screen readers.
  • Use Google Webmaster Tools and Bing Webmaster Tools.
  • Know how robots.txt and search engine spiders work.
  • Redirect requests (using 301 Moved Permanently) asking for www.example.com to example.com (or the other way round) to prevent splitting the google ranking between both sites.
  • If you have non-text content look into Google's sitemap extensions for video etc. There is some good information about this in Tim Farley's answer.


  • Understand HTTP and things like GET, POST, sessions, cookies, and what it means to be "stateless".
  • Write your XHTML/HTML and CSS according to the W3C specifications and make sure they validate. The goal here is to avoid browser quirks modes and as a bonus make it much easier to work with non-traditional browsers like screen readers and mobile devices.
  • Understand how JavaScript is processed in the browser.
  • Understand how JavaScript, style sheets, and other resources used by your page are loaded and consider their impact on perceived performance. It is now widely regarded as appropriate to move scripts to the bottom of your pages with exceptions typically being things like analytics apps or HTML5 shims.
  • Be aware that JavaScript can and will be disabled, and that AJAX is therefore an extension, not a baseline. Even if most normal users leave it on now, remember that NoScript is becoming more popular, mobile devices may not work as expected, and Google won't run most of your JavaScript when indexing the site.
  • Consider using a Reset Style Sheet or normalize.css.
  • Consider JavaScript frameworks (such as jQuery, MooTools, Prototype, Dojo or YUI 3), which will hide a lot of the browser differences when using JavaScript for DOM manipulation.
  • Taking perceived performance and JS frameworks together, consider using a service such as the Google Libraries API to load frameworks so that a browser can use a copy of the framework it has already cached rather than downloading a duplicate copy from your site.
  • Don't reinvent the wheel. Before doing ANYTHING search for a component or example on how to do it. There is a 99% chance that someone has done it and released an OSS version of the code.
  • On the flipside of that, don't start with 20 libraries before you've even decided what your needs are. Particularly on the client-side web where it's almost always ultimately more important to keep things lightweight, fast, and flexible.

Bug fixing

  • Understand you'll spend 20% of your time coding and 80% of it maintaining, so code accordingly.
  • Set up a good error reporting solution.
  • Make frequent backups! (And make sure those backups are functional) Ed Lucas's answer has some advice. Have a restore strategy, not just a backup strategy.
  • Use a version control system to store your files, such as Subversion, Mercurial or Git.
  • Don't forget to do your Acceptance Testing. Frameworks like Selenium can help.
  • Make sure you have sufficient logging in place using frameworks such as log4j, log4net or log4r. If something goes wrong on your live site, you'll need a way of finding out what.
  • When logging make sure you capture both handled exceptions, and unhandled exceptions. Report/analyse the log output, as it'll show you where the key issues are in your site.

Lots of stuff omitted not necessarily because they're not useful answers, but because they're either too detailed, out of scope, or go a bit too far for someone looking to get an overview of the things they should know. Please feel free to edit this as well, I probably missed some stuff or made some mistakes.

Some of your SEO suggestions are bad. It doesn't matter if you use tables or divs (Google confirmed this themselves). That SEF URL thing... I hate those "fake URLs", where the ID is the only thing that actually determines the page. "45-blah" would be the same page. It's not user-friendly either. –  DisgruntledGoat Mar 6 '09 at 0:29
Then edit it. I didn't write most of this: I'm only maintaining it -- a job which I've inherited because I asked the question, solicited this larger answer specifically, and I'm genuinely interested in seeing what we can come up with. The more contributions the better. –  Joel Coehoorn Mar 16 '09 at 1:18
One more note: if you do come back and edit this, try to be respectful of what was written. Don't just remove the parts you disagree with: actually take the time to address the short-comings and provide something better. –  Joel Coehoorn Mar 16 '09 at 1:19
One thing I suggest you add to your security section, is that all files you serve up should be compared to a whitelist of allowed folders, or to "jail" the webserver. This stops someone using http://server/download.php?file=../../etc/password. Never expose file paths to the user. –  Philluminati Feb 12 '11 at 13:24
As an example, you don't just jump into a car and start driving. Instead, you take classes on the proper operation of that car and ultimately have to pass a test proving you can drive. For some, that takes many, many, many hours of study. And yes, I'd equate learning how to properly build a web application with learning to drive a car as failure to properly build an application can certainly result in a larger degree of disruption of peoples lives than a simple fender bender, including a much larger financial loss. Death? well, depends on what type of app the developer screwed up. –  Chris Lively Apr 24 '12 at 4:36
show 10 more comments
