This note is about website development. Related to web design.
Use image formats in the right context. Use PNG for the web layout as it has transparency and is lossless. Use JPG for big images like photos, usually part of the content, not the layout. Use GIF for animated images and only if you know what you are doing.
Make sure you have clean and short URLs. Even if they are rarely written, messy URLs look unprofessional.
Only show share buttons after a positive experience. Consider lazy loading social plugins only when user hovers or clicks the share buttons.
Make it personalized. If you have registration, include user's name and company name in all possible places it might be relevant. Personalization makes the visitor feel important.
Never interrupt the browsing experience. Limit number of popups, ads and survey requests. Users hate them a lot.
Learn debugger tools at your disposal. These tips are for mainly for Chrome but Firefox/Firebug and Opera surely have most of the same functionality available somehow. When I state "browser" in this note, I generally mean Google Chrome.
- JS Breakpoints: Notify when code execution arrives as specific line. If you develop with minified JS, there should be pretty print JS functionality in browser development tools. Some browsers have support for
- DOM Breakpoints: Notify on DOM element change or child change.
- Events Monitors: Write
monitorEvents(document.body, 'mouse');to console.
- Script Mapping: Allows you to link a remote file in browser to a local file in your development environment. So changing file in browser changes the original file. Allows debugging of minified code.
Always benchmark your response time. The most important benchmarking metric is response time. User should not have to wait more than 2 seconds for the response.
200ms OK 500ms Pretty bad, you start losing visitors. 1000ms Big cut on visitor count, people feel that the site is really slow.
Use tools. They help you to benchmark your optimizations and suggest additional fixes.
- Pingdom: benchmark loading speed.
- WebPageTest: benchmark loading speed.
- Google Insights: gives a score for a page by problems on the page.
- Yahoo YSlow: gives a score for a page by problems on the page.
- GTmetrix: web application for website optimization.
Easy tasks to improve page load speed:
- Including CSS at the header.
- Include JS at the bottom of your body.
- Turn on server side compression (gzip).
- Compress your images to JPGs and PNGs.
- Specify image sizes for your images so browsers do not need to calculate.
- Add expires header to static content e.g. a year.
- Disable crawling on scripts with robots.txt.
- Enable keep alives.
More tough tasks to improve page load speed:
- Remove social network buttons. Make them load on mouse hover or use custom ones.
- Replace images with CSS3, check which browsers you must support.
- Replace images with image sprites.
- Replace icon images with an icon font.
- Replace small images with data URIs embedded in CSS.
Avoid using external resources. Additional DNS lookups will make your page slower. Upload everything you can on your own server.
Twitter feed, YouTube videos, Flicker images.
PHP requires an accelerator. Use Alternative PHP Cache (APC) or XCache to boost PHP performance. Other programming languages do not need accelerator in the most cases.
Benchmark your memory for memory leaks. If graph goes up and up, you have a memory leak. You can use heap snapshots to see what takes memory. Detached DOM trees are usually the cause of memory leaks.
Timeline -> Memory -> Start Recording -> *do stuff* -> End Recording Take Snapshot 1 -> *do stuff* -> Take Snapshot 2 -> Compare 1 with 2
Timeline -> Frames
<canvas> to replace a lot of DOM elements. Create a cabvas and draw elements inside the canvas. Canvas element is only one node.
Detach elements from DOM while you are manipulating them.
var $table = $('#some-table'); var $parent = table.parent(); $table.detach(); $table.addLotsAndLotsOfRows(); $parent.append($table);
Plan your server setup. You should at least use separate application and database servers which allows easier scaling. Having a separate API server might be applicable in some situations.
- All on One Server: Simple. Poor performance because all parts of the service use the same resources. Poor scalability if not prepared for.
- Application Server -> Database Server: Simple. OK performance as application and database are on different servers. OK scalability as you can upgrade application or database. Prepared for high communication between application and database server.
- Cache -> Application Server -> Database Server: Complex. Use a HTTP accelerator server to cache responses from the application server. Great for pages with dynamic content. Requires a lot of tuning.
- Balancer -> Application Servers -> Database Server: Complex. Load balancer as the access point that redirects requests to multiple application servers, while having one database server. Great for all websites with a lot of traffic.
- Balancer -> Application Servers -> Master Database + Slave Databases : Very complex. Use multiple database servers where one acts as master and others as slaves. Writes made to master can be read from all slaves. Great for web services with a lot of reads compared to writes.