Top 15 Things to Check for When Launching Your Shiny New Site

Ahh, launch day. A stressful, nerve racking and ultimately exciting time!  You stay late, you bust your butt getting things working and then you push things up live…only to come into work the next day to a soon to be behemoth sized email thread of fixes. Well, one way to prevent the “morning after” blues of a launch is to run things through a checklist. Depending on how meticulously you’ve been keeping things in the creation process, this could be a very quick thing to run through, or if you’ve been a little rushed getting to launch, it could take a few hours. In the end though, its worth it all to have a spit and polished site instead of a contact from your boss, or heaven forbid, your client that it something is broken. The answer? A launch checklist!

I’ve included a list of a few of the things we check for here in the dt office before we push a site live. Some of these are simple like spelling and grammar (which should always be checked long before it even gets to content flow), down to a few “professional” finishing touches. A good way to keep track of if things are being each time is to take a list like this and setup a form that you can go through each time you deploy something. Check out the ever famous Wufoo or even use Google Doc’s Form Creator for a truly free version.

1. Check for incorrect punctuation, spelling, and grammar. Nothing more embarrassing when you’ve got something spelled wrong, especially when you’ve got a million tools to check it.
2. Capitalization Consistency. Its important to provide a consistent presence for yours or your client’s brand. Make sure that whenever you reference it you use proper and consistent camel casing and capitalization.
3. Variations in words. It is very common, especially when multiple people are writing copy, to have a lot of variance in how things are referred to. Make sure there’s consistency between websites and web sites or UK and United Kingdom.
4. Check for hard-coded links to staging/development domains. Kill those localhost references and hash-tagged links!
5. Ensure no test content is on the site. Make sure you’ve removed any “for positioning only” images, lipsum text, etc.
6. Check all “hidden” copy. A very easy thing to over look. Make sure your alt attributes, title attributes, even comments are clean and appropriate for anyone and everyone to view.
7. Validate your HTML and CSS. Run your site through the W3C validator. This should be something you do as you’re developing as well as it can point out problematic DOM markup. Check your site out at http://validator.w3.org/ and your CSS at http://jigsaw.w3.org/css-validator/.
8. Check your layout on common browser variations. This is really important for a proper launch. Make sure that you have run your site through all common browser versions on multiple platforms, not just the one you’ve been developing on. It is usually safe to validate against the latest versions of Safari, Firefox and Chrome as their distributors have fairly aggressive, if not automatic upgrade paths. When it comes to Internet Explorer however, you’re going to still need to test for IE 7 and 8, and if you’ve agreed to it with your client IE 6, although we recommend you try to steer your client away from that last one
9. Check your layout on common variations of screen resolution. Sites usually look great on a 1280×1024 screen or larger… but not everyone has 2-3 monitors and runs at the absurdly high resolutions that most designers and developers do. Its very easy to forget that a 980 pixel wide layout will break horizontal scrolling in most browsers on a 1024×768 screen. A quick way to check for lower resolutions is to get a resizer plugin for Firefox and load it up there. There’s about a million of them, so it should be easy to find.
10. Test without JavaScript, Flash and other plugins. With the proliferation of high-speed internet and the focus on modern browser security its hard to think that someone might not have Flash installed or JavaScript turned on, but this isn’t so much an issue of someone not having the latest plugin as a need for reliable multi-platform deliverability. Will your site work on a mobile browser? What about a kiosk or locked down internet cafe machine?
11. Run applicable JavaScript files through JSLint. JSLint will make you cry, but it’ll make your JavaScript super shiny…and prep it to be fully packed and Base62 obfuscated for size and security. JSLint runs through your JavaScript and points out everything you did wrong according to an extremely rigid set of parameters, akin to W3C validation for your XHTML and CSS. The great thing is it also suggests ways to fix it and really bullet-proof your code.
12. Pack your JavaScript. The biggest thing slowing your site down is all the crap you load in the header. The quickest way to improve site load time is to shrink down the heavy libraries being used by your site’s awesome design. You can even get the weighty Prototype library compressed down if you spend an hour or two going through it with JSLint and add semi-colons where they should be (common Prototype guys, this is sloppy, you should fix this).
13. Minimize your CSS files. Create minimized versions of your CSS files with CSS Drive’s CSS Compressor and take a few more Kb off your site load. Don’t replace your main CSS files with these minimized versions as their a pain to edit, just make a copy and use the compressed versions for the live production deployment.
14. Run your images through PunyPNG. Take even more weight off of your website by making those images even tinier – without a loss in image quality. Run as many images as you can through the PunyPNG tool and take a few Kb off your page load.
15. Clean up your production server. The web is dynamic, always changing, which unfortunately yields some extremely messy production server environments with loads of orphaned files. Start things right by making sure you’ve removed the un-compressed versions of JavaScript files, un-used images, un-minimized CSS files, etc. Only deploy whats used.

Got a list of things you check for whenever you deploy a new website or update? Comment about it below!