Boost Web App Speed: Client & Server Performance Tips
Web Application Performance
Performance Issues
- Client-side
- Server-side
Client-Side Performance
- Minimize HTTP Requests
- Fewer requests per page rendering mean faster time.
- Combine files such as scripts, images, etc.
- CSS Sprites, Image maps, etc. for images.
- Combine multiple JS files, manually or using a tool like YUI compressor.
- Remove duplicate scripts.
- Reduce Content Size
- Reduce transfer time.
- Remove unnecessary tags.
- Compress files (Browser supported: Gzip).
- Minification of Javascript and CSS:
- YUI Compressor, JSMin, etc.
- Post-load components (Ajax, YUI Get Utility).
- Make Use of Browser Idle Time
- Flush the buffer early.
- Preload components.
- Make Use of Cache
- Make Javascript and CSS external.
- Cache static resources.
- ETags.
- Parallelize Downloads
- Create multiple domains.
- Download resources in parallel.
- Reduce Latency, Network Transfer Time
- Exploit proximity, deploy on geographically dispersed servers.
- Use CDN.
Server-Side Performance
- Balance the Load
- Optimize Database
- Too many database queries make applications slow.
- Use indexes / query optimization techniques.
- Cache Data
- Memcache
- Parallelize
- Use threads / asynchronous operations.
- Make best use of available CPU during I/O.
- Consider thread pools to avoid the cost of creation / destruction of threads.
Measure Performance
- Key to improvement is measurement.
- Use tools for performance testing:
- Server-side: Jmeter
- Client-side: Profiling tools, Chrome Developer Tools
Man-in-the-Middle Attacks on SSL
Man-in-the-middle attacks on SSL are really only possible if one of SSL’s preconditions is broken. Here are some examples:
- The server key has been stolen – This means the attacker can appear to be the server, and there is no way for the client to know.
- The client trusts an untrustworthy CA (or one that has had its root key stolen) – Whoever holds a trusted CA key can generate a certificate pretending to be the server, and the client will trust it. With the number of CAs pre-existing in browsers today, this may be a real problem. This means that the server certificate would appear to change to another valid one, which is something most clients will hide from you.
- The client doesn’t bother to validate the certificate correctly against its list of trusted CAs – Anyone can create a CA. With no validation, “Ben’s Cars and Certificates” will appear to be just as valid as Verisign.
- The client has been attacked, and a fake CA has been injected into his trusted root authorities – This allows the attacker to generate any cert he likes, and the client will trust it. Malware tends to do this to, for example, redirect you to fake banking sites.
Especially #2 is rather nasty. Even if you pay for a highly trusted certificate, your site will not be in any way locked to that certificate. You have to trust all CAs in the client’s browser since any of them can generate a fake cert for your site that is just as valid. It also does not require access to either the server or the client.