One of the biggest things you can do to protect against timing attacks is to use proper cryptographic libraries and the helper functions they provide (for example, if you're using the bcrypt.js library, use the compare function that it provides, rather than doing your own string comparisons). Any time you try and implement your own crypto it's probably going to be vulnerable to timings attacks.
These kind of attacks can be very hard to perform though - there are (normally) very small differences in the time to compare strings, for example, which would be harder to detect over the internet (although you can work around this with large samples).
The attacks that are easier to exploit are often where there's some kind of external interaction from your code. For example, a password reset feature might have to send an email (which can be slow) if the username is valid, and may just return immediately if it's not. Asynchronous external calls can help here (and are probably better for the user anyway).
Most timing attacks rely on an attacker being able to make a large number of scripted requests and analyse the response times, so anything you can do to make this harder (for example, rate limiting or a CAPTCHA) will also provide you a degree of protection. It doesn't necessarily solve them, but it would make them harder to pull off.
Realistically, unless you're doing something crypto related, there are probably bigger threats to worry about.
Edit: A few years after making this post, the Bcrypt.js developers discovered that their timing-safe string comparison function actually wasn't. In the context they're using it (comparing hashes) it's not an exploitable issue, but it shouldn't be used for anything where timing attacks are a concern.