Download to read offline
Uploaded byHelgi Þormar Þorbjörnsson
Caching for Cash, part 4 DPC 2009
This document discusses various techniques for improving website performance and reducing page load times, such as reducing the number and size of HTTP requests, optimizing files by minifying and compressing code, leveraging browser caching, and using content delivery networks. Some specific recommendations include minimizing unnecessary cookies, combining and compressing JavaScript and CSS files, moving scripts lower on pages, using cache headers, and testing pages on slow connections to identify bottlenecks.
More Related Content
Similar to Caching for Cash, part 4 DPC 2009
Caching for Cash, part 4 DPC 2009
- 1. Caching For CashDutch PHP Conference – Amsterdam, June 2009
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. 80% of response time is spent downloading content
- 8.
- 9.
- 10. “ It alldepends on how we look at things, and not how they are in themselves.” - Carl G. Jung
- 11.
- 12.
- 13. Key factor inperformance Fewer HTTP Requests Easy to improve on
- 14. Sent with staticcontent Slow upstream speed Big cookies
- 15. Cookie Size ResponseTime (Delta) 0 bytes 78 ms ( 0 ms ) 500 bytes 79 ms ( +1 ms ) 1000 bytes 94 ms ( +16 ms ) 1500 bytes 109 ms ( +31 ms ) 2000 bytes 125 ms ( +47 ms ) 2500 bytes 141 ms ( +63 ms ) 3000 bytes 156 ms ( +78 ms ) Times are for page loads on DSL (~800 kbps).
- 16. Eliminate unnecessary cookiesKeep sizes low Appropriate domain levels Set Expires date appropriately
- 17. Be aware ofmax connection limits in browsers CNAME to point multiple sub domains to the same IP
- 18. One domain =2 Parallel connections
- 19. Two domains =4 Parallel connections
- 20. Too many hostnamescan cause complications 2 – 4 sub domains is a good average
- 21. Combining 6 scripts into 1 eliminates 5 requests Challenges: develop as separate modules
- 22. combinations vs. loadingmore than needed
- 23. JS does notcomply with the parallel downloading rule
- 24. script defer attribute is not a solution blocks rendering and downloads in FF
- 25. slight blocking inIE Solution: move them as low in the page as possible
- 26. Crushes the filesStrips out all cruft Voodoo magic
- 27. JSMin Dojo ShrinksafePacker YUI Compressor http://short.ie/compression-rates
- 28. You can affect users download times
- 29. Gzip can beused on JS
- 30.
- 31.
- 32.
- 33. Gzip should not be used on Images
- 34.
- 35.
- 36.
- 37.
- 38. Badly optimized ThumbnailsPNG can be compacted 50%, no quality loss OptiPNG
- 39. Test on slowconnections Slow proxies for developers
- 40. Data served througha single domain Smart routing software Data closer to the end user – Less latency
- 41.
- 42. Appropriate dates Cachefar in the future Change file names on releases
- 43. Hash tag tocompare between browser and server Gives more flexibility than last-modified-date Great on a single server setup
- 44. Typically unique toa server Disable if not being used!
- 45. Use options thatare not unique per server
- 46. Firebug Firecookie YslowPage Speed Hammerhead http://stevesouders.com/hammerhead/ http://code.google.com/speed/page-speed
- 47. “ Knowledge restsnot upon truth alone, but upon error also.” - Carl G. Jung
Editor's Notes
- #9 The user’s perception is more relevant than actual unload-to-onload response time. Definition of "user onload" is undefined or varies from one web page to the next.
- #12 User needs to download all components Coming for the first time Force refresh of the site Browser automagically cleared the cache based on settings
- #13 User needs to download all components Coming for the first time Force refresh of the site Browser automagically cleared the cache based on settings
- #16 Yahoo ran the experiment. Ran against an empty page
- #18 Older IE: 6 overall, 2 per host Older FF had 24 as overall and 8 per host Newer FF: 30 overall, 15 per host
- #21 Many host names = more DNS lookups, adds delay Consider the effects of CPU thrashing for the client Lookup times vary across ISPs and geographic locations
- #22 dynamically combine and cache Combine and minimize before a release
- #31 Don't use HTMTL attributes to scale Favicon – keep it around, keep it small
- #37 Hash like tag to compare browser cache against the server version Only download if hash has changed Gives more flexibility than last-modified date Great on a single server setup
- #38 Typically unique to a server Default behavior in Apache and IIS If hash don't match between server, then browser cache is not used Proper Expires Headers won't help Remove ETags if not being used to its fullest