Front-End Optimization (FEO)


Published on

Improving Site Response Time, Part 1

Published in: Technology

Front-End Optimization (FEO)

  1. 1. Improving Site Response Time Part 1: Front-End Optimization (FEO)Kim Stefan Lindholm 1 26.1.2012
  2. 2. SETUP• Server: CloudControl (Dublin, Ireland) with local Varnish HTTP accelerator• CMS (Content Management System): Joomla 1.5• WAF (Web Application Firewall): Incapsula• CDN (Content Delivery Network): Akamai (Rackspace) & Amazon CloudFront• Anycast DNS: DNS Made Easy NB: Incapsula and Akamai automatically serve compressed (gzip) files 2
  3. 3. RESULTS Proxy servers may take some time to refresh their cache, which can delay performance improvement. Browser & server cache + compression Minify images, CSS & JS CombineGzip HTML, CSS & JS Inline images,No caching Pre-gzip, CDN Main page, average response time (ms) 3 Pingdom Panel, global average
  4. 4. LOAD TIME18 s14 s Original 9s Caching CloudFront, inline, gzip 5s Amsterdam Dallas, TX Dulles, VA Jiangsu, China 4
  5. 5. LOAD TIME Amsterdam Dallas, TXChrome Chrome -87% -69% Dulles, VA Jiangsu IE 8 IE 7 -51% -64% 5
  6. 6. How much were we able to decrease costly HTTP requests? 6
  7. 7. CACHED VS. FINAL HTTP Requests -83% Total Weight -30% Original total weight was 206K 7 Yahoo YSlow add-on for Chrome
  8. 8. Did Incapsula web proxy/firewall contribute to the results? 8
  9. 9. INCAPSULAIncapsula caching seemed to be affected by incoming traffic (site popularity) and not so much by changes in the website itself (cacheability etc.) 9
  10. 10. Speed difference between Incapsulaproxy and global CDN (measured in Europe)? 10
  11. 11. PROXY VS. CDN Average load speed (real) tested with 10 iterations: time curl [--compressed] <url> > /dev/null2,500 ms1,875 ms No proxy Incapsula Incapsula, gzip1,250 ms Compressed Akamai size: 34k Compressed Akamai, gzip size: 3k Slowest 1st load: 1400 ms 625 ms mootools.js (116k) template.css (11k) template_ie7.css (2k) 11
  12. 12. PROXY VS. CDN• Standarddeviation with Akamai CDN was notable. At worst, fetching a 2k file was 3x slower than with the original unproxied connection.• Withcompression on, first loads seemed very slow. This is acceptable, of course, if gzipping and pushing to cache only happens infrequently.• Given the additional overhead of compression and DNS lookups, small files (<10k) are not automatically perfect candidates for CDN. Combine images using sprites instead. 12
  13. 13. Speed difference between Akamai and Amazon CloudFront? 13
  14. 14. CDN COMPARISONAkamai, gzip CloudFront, gzip 14 Pingdom Panel, Response time report
  15. 15. CDN COMPARISON Main page first load speed, CDN allowed to propagate for one day9s7s Akamai, gzip CloudFront CloudFront, gzip5s2s Amsterdam Dallas Los Angeles Singapore Tokyo 15
  16. 16. CDN COMPARISON Main page second load speed, CDN allowed to propagate for one day9s7s Akamai, gzip CloudFront CloudFront, gzip5s2s CDNs seem quite equal in performance. Amsterdam Dallas Los Angeles Singapore Tokyo 16
  17. 17. RE VIS PROXY VS. CDN ITE DAverage load speed (real) tested with 3 iterations: time curl --compressed <url> > /dev/null File: css-main-data.gz.css (73k) Transparent bar denotes 1st load13 s10 s Incapsula, gzip 8s Akamai, gzip CloudFront, gzip 5s 3s Akamai was the steadiest performer Norway UK US Japan globally. 17
  18. 18. LEARNINGS• CDN for large files and gzipping are always good for performance• CDN for small files can actually slow down performance• Parallelizing across hosts works fine (2-4 hosts recommended by Yahoo)• Options for gzipping CSS & JS: (1) Pre-compress and serve the right version (fastest), (2) done by server on the fly (easiest), (3) done by application (can be slow)• Realistic comparison of CDNs would require weeks of monitoring 18
  19. 19. CHECKLIST✓ Minify and combine CSS & JavaScript (load JS asynchronously when possible)✓ Compress images and use web/tablet/smartphone resolutions✓ Combine small images into sprites or use inline images with data URIs (IE7 requires MHTML:✓ Gzip HTML, CSS & JS. Pre-compress files when possible.✓ Load large resources from CDN, possibly using multiple hosts✓ Long cache TTL for static assets + invalidate with versioning (main-xyz.css / main.css?xyz)✓ Advanced: lazy loading, async CSS, HTML5 cache, JS pre-execution, response prediction 19
  20. 20. APPENDIX 20
  21. 21. Start Repeat Requests Load time Page size First byte render viewOriginal Amsterdam, Netherlands 43 3.9 s 206 kB Dallas, TX, USA 43 7.8 s 206 kB Dulles, VA, USA 44 4.7 s 227 kB 1.5 s 2.8 s 4.0 s Jiangsu, China 45 17.3 s 228 kB 2.9 s 8.0 s 13.8 sCaching Amsterdam, Netherlands 43 1.3 s 161 kB Dallas, TX, USA 43 3.1 s 161 kB Dulles, VA, USA 44 3.3 s 180 kB 1.0 s 2.0 s 2.7 s Jiangsu, China 44 11.2 s 178 kB 2.1 s 6.2 s 9.5 sParallel CDNs (CloudFront), Combined images, Pre-gzip Amsterdam, Netherlands 37 0.5 s 113 kB Dallas, TX, USA 37 2.4 s 113 kB Dulles, VA, USA 6 2.3 s 114 kB 0.9 s 2.1 s 0.8 s Jiangsu, China 26 6.2 s 145 kB 2.1 s 3.9 s 1.3 s 21
  22. 22. JOOMLA SETTINGS• JotCache plugin • CDN for Joomla plugin NB: images must be present in CDN if locally referenced from CSS 22
  23. 23. RESOURCES - ANALYTICS• Pingdom Full Page Test,• WebPageTest,• REDbot (cache testing),• Loads In,• Cloud Speed Test (CDN comparison),• DNS Check, 23
  24. 24. RESOURCES - COMPRESSION•,• YUI Compressor, java -jar yuicompressor-2.4.7.jar -o .css$:-min.css *.css java -jar yuicompressor-2.4.7.jar -o .js$:-min.js *.js• In case you need to manually copy all assets to CDN: tar c $(find <source_dir> ( -name "*.bmp" -o -name "*.gif" -o -name "*.jpg" -o -name "*.jpeg" -o -name "*.png" -o -name "*.css*" -o -name "*.js*" )) | tar xv -C <dest_dir>• SmartSprites,, SpriteMe, 24