Making Grails Web Sites Fast

Front end performance optimization with Grails
GR8Conf US 2013

Transcript

1. Making Grails Web Sites Fast Ken Liu GR8Conf US 2013
2. About me Web development with Java since JDK 1.0.2 (applets, anyone?) Groovy and Grails since 2009 Lead developer for IEEE Spectrum
3. About IEEE / IEEE Spectrum Institute of Electrical and Electronics Engineers Widely known for standards - 802.3, 802.11 World’s largest technology professional association - 400,000 engineers in 160 countries Publishes nearly a third of the world’s technical literature in EE/CS IEEE Spectrum http://spectrum.ieee.org - 100% Grails
4. Agenda Why focus on web performance? How to assess website performance Tools and techniques for improving performance Grails plugins for web performance
5. Agenda Why focus on web performance? How to assess website performance Tools and techniques for improving performance Grails plugins for web performance
6. Why does web performance matter? 400ms delay = 5-9% drop in page traffic (Yahoo) 100ms delay = 1% drop in revenue (Amazon) 1s improvement = up to 2% conversion rate (Walmart) 57% of online consumers will abandon a site after waiting 3 seconds for a page to load. 80% of these people will not return (Akamai) 250ms delay = users will visit website less than competitors (Microsoft) Akamai http://www.akamai.com/html/about/press/releases/2010/press_061410.html Yahoo http://www.slideshare.net/stoyan/yslow-20-presentation Amazon http://sites.google.com/site/glinden/Home/StanfordDataMining.2006-11-28.ppt?attredirects=0 Walmart http://minus.com/msM8y8nyh#2e http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html
7. What makes websites slow? Slow server performance Network latency Heavyweight/unoptimized web pages Third-party social network widgets and beacons Ad serving China firewall
8. Agenda Why focus on web performance? How to assess website performance Tools and techniques for improving performance Grails plugins for web performance
9. What is “fast” anyway? Industry benchmarks such as published by Keynote A site might be fast in NJ but slow in CA …or Asia User perception trumps absolute performance metrics You don’t know if something is fast or slow unless you measure it
10. “14 Rules for Faster-Loading Web Sites” Steve Souders Chief Performance Yahoo! circa 2007
11. The Performance Golden Rule “80-90% of the end-user response time is spent on the frontend. Start there.” - Steve Souders
12. The Performance Golden Rule “backend” time is the time it takes for the initial HTML page to start downloading ~0.4s out of ~2.0s Source: http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
13. Understanding waterfall charts http://www.strangeloopnetworks.com/blog/how-to-use-a-waterfall-chart-to-interpret-web-performance-data/
14. Understanding waterfall charts http://www.strangeloopnetworks.com/blog/how-to-use-a-waterfall-chart-to-interpret-web-performance-data/
15. Understanding waterfall charts: patterns First line: Initial HTML page (incl. TTFB) Lots of lines: too many objects Long lines: slow downloading objects Wide chart: slow overall page load Total page weight, total page load time, response codes
16. Agenda Why focus on web performance? How to measure website performance Tools and techniques for improving performance Grails plugins for web performance
17. “14 Rules for Faster-Loading Web Sites” Rule 1 - Make Fewer HTTP Requests Rule 2 - Use a Content Delivery Network Rule 3 - Add an Expires Header Rule 4 - Gzip Components Rule 5 - Put Stylesheets at the Top Rule 6 - Put Scripts at the Bottom Rule 7 - Avoid CSS Expressions Rule 8 - Make JavaScript and CSS External Rule 9 - Reduce DNS Lookups Rule 10 - Minify JavaScript Rule 11 - Avoid Redirects Rule 12 - Remove Duplicate Scripts Rule 13 - Configure ETags Rule 14 - Make AJAX Cacheable
18. Yahoo! 34 Rules Make Fewer HTTP Requests Use a Content Delivery Network (CDN) Add Expires or Cache-Control Header Gzip Components Put Stylesheets at Top Put Scripts at Bottom Avoid CSS Expressions Make JavaScript and CSS External Reduce DNS Lookups Minify JavaScript and CSS Avoid Redirects Remove Duplicate Scripts Configure ETags Make Ajax Cacheable Flush Buffer Early Use GET for Ajax Requests Postload Components Preload Components Reduce the Number of DOM Elements Split Components Across Domains Minimize Number of iframes Avoid 404s Reduce Cookie Size Use Cookie-Free Domains for Components Source: http://developer.yahoo.com/performance/
19. Front-end performance analysis tools Browser-based tools Google Chrome Developer Tools + Google Page Speed Insight Extension Firefox Firebug + YSlow Web-based tools webpagetest.org Google Page Speed Insights
20. demos: YSlow and webpagetest.org
21. Key front end performance strategies Reduce effect of network latency Show content to the user as quickly as possible Only download what you need, when you need it Cache stuff so it doesn't have be loaded more than once
22. Make fewer HTTP requests Reduce the number of objects on a page Many small objects slower than few larger objects Combine many small files into one Delay loading of content, especially hidden content More requests = more waiting Many of the “rules” are aimed at this goal
23. Use a Content Distribution Network (CDN) Akamai, Amazon CloudFront, Limelight, CloudFlare Global network of servers - reduces network latency Web cache Be careful of changing cached content
24. Use a Content Distribution Network (CDN) https://en.wikipedia.org/wiki/File:NCDN_-_CDN.png Traditional network vs. CDN
25. Use a Content Distribution Network (CDN) Source: http://blog.letshost.ie/2012/02/letshost-launches-new-content-delivery-network-service/ Visitors connect to “closer” servers, lower latency
26. Gzip components The easiest no-brainer optimization, just do it! Enabled at the web server - “Accept-Encoding” header Gzip all text content (CSS, JS, HTML, JSON, XML) Don't Gzip binary content (images, PDFs, video files)
27. Gzip components Compressing the following resources with gzip could reduce their transfer size by 366.2KiB (80% reduction). • Compressing /assets/css/site.css could save 145.8KiB (87% reduction). • Compressing /getGlobalNavData could save 98.3KiB (85% reduction). • Compressing / could save 44.8KiB (75% reduction). • Compressing /assets/js/script1.js could save 30.4KiB (75% reduction). • Compressing /.../jquery.isotope.min.js could save 10.6KiB (68% reduction). • Compressing /assets/js/libs/plugins.js could save 10.0KiB (66% reduction). • Compressing /.../modernizr-2.5.3.min.js could save 9.0KiB (60% reduction). • Compressing /assets/css/style.css could save 6.8KiB (68% reduction). • Compressing /assets/js/libs/spin.min.js could save 2.1KiB (51% reduction). • Compressing /.../jquery.lazyload.min.js could save 2.0KiB (64% reduction). • Compressing /assets/js/slimbox2.min.js could save 1.8KiB (53% reduction). • Compressing /assets/css/sb.css could save 1.2KiB (66% reduction). • Compressing /.../spec4-style-updates-1-30.css could save 970B (69% reduction). • Compressing /.../jquery.touchwipe.min.js could save 813B (52% reduction). • Compressing /.../masonry-ads-right.min.js could save 798B (58% reduction). • Compressing /assets/css/slimbox2.css could save 698B (56% reduction). Enabling gzip compression - Spectrum home page 366.2 KiB (80%) reduction (total 1.2 MB)
28. Optimize browser caching First visit (empty cache) vs. repeat visit (primed cache) Set cache headers in application or web server Cache images forever (set “expires” header) Rename objects when updating to facilitate caching Can be more complex than it seems Tread carefully - once objects are cached in users’ browsers, you can’t easily remove them
29. Optimize browser caching IEEE Spectrum First view vs. Repeat view
30. CSS & JS minification Different than gzip compression Logical compression, some advanced smarts Google Closure compiler, Yahoo YUI Compressor Use minified versions of JS libraries (*.min.js) Concatenate CSS and JS files Use tools for bundling assets
31. CSS & JS minification
32. CSS at the top in <head> JS at the bottom, before </body> CSS at the top allows page to render immediately JS at the bottom allows JS to execute after HTML is loaded Order resources in the page
33. Compress JPG/PNG images efficiently (lossy) Optimize JPG/PNG compression (losslessly) Don't scale down images Smush.it - integrated into YSlow PunyPNG, ImageOptim, OptiPNG, others Automate in your CMS / web development process Optimize images
34. Image spriting Don’t do image slicing! Combine tiny icons/graphics into “sprite sheet” Downsides - maintenance, retina support
35. Image lazy-loading Post load images using jQuery lazyload plugin http://www.appelsiini.net/projects/lazyload jQuery plugin captures onScroll events and loads images that are in the viewport
36. HTML5/CSS3 techniques Use CSS3 rounded corners, drop shadows, gradients, not images Old browsers get degraded, but functional, appearance
37. Async loading and AJAX Use AJAX to refresh parts of page or load parts after document ready Cache AJAX responses Beware of impacts to analytics, ad serving, page history, etc. Can add significant application complexity May break searchability
38. Agenda Why focus on web performance? How to measure website performance Tools and techniques for improving performance Grails plugins for web performance
39. UiPerformance plugin Granddaddy of all web performance plugins “Swiss Army knife” approach No longer maintained, replaced with Resources plugin family
40. Grails resources plugin family Powerful plugin framework for web performance concerns Many additional plugins that collaborate with grails- resources processing pipeline Does some processing at runtime instead of build time Stores generated files locally?
41. Grails resources usage Declare “modules” (groupings of resources) in ApplicationResources.groovy (by convention) Declare GSP dependencies on modules using <r:require> insert <r:layoutResources> on pages to include declared resources
42. Resources plugin: Using a CDN Example CloudFront domain: d1209ystrpttii.cloudfront.net set grails.resources.mappers.baseurl.default = "d1209ystrpttii.cloudfront.net" mapped resources will now point to CDN domain
43. Resources plugin: Dispositions Implements rules for resource ordering By default, CSS is placed in <head> and JS at the end of the document (“defer”) Can override defaults for special cases
44. Resources plugin: Compressing/minifying CSS Google closure compiler plugin set options for compilation level: WHITESPACE_ONLY, SIMPLE_OPTIMIZATIONS, ADVANCED_OPTIMIZATIONS YUI compiler plugin is abandoned!
45. Cached-resources plugin Takes care of object versioning problem, facilitates caching resources “forever” Facilitates CDN caching and browser caching No need for manual object versioning - generates file names based on SHA of file contents
46. Resources plugin: Concatenating JS/CSS Can declare bundle property on resource declaration Eases maintenance of code - use smaller files during development without performance hit Changing one of the resources in the bundle will trigger a rebuild of the bundle
47. Zipped resources plugin Automatically gzips static resources and caches in server May be better/easier just to set gzip at web server
48. Cache Headers plugin
49. The server side The first 10-20% TTFB (time-to-first-byte) means blank screen Don't confuse server load with front end performance - test separately Database query performance Server-side caching (cache plugin family) Server memory, thread contention, disk performance
50. The server side: cache plugins Springcache plugin: deprecated in favor of cache plugin family Cache-ehcache, Cache-redis, Cache-gemfire extensions Cache GSPs: @Cacheable annotation on controller methods Cache Services: @Cacheable on services Be careful to set cache key correctly for services
51. Automated WPO Trade off money for performance/developer time Reverse proxy to automatically apply performance optimizations on-the-fly Akamai Blaze, Strangeloop, Google PageSpeed Service, many others mod_pagespeed - many experimental optimizations available https://developers.google.com/speed/pagespeed/
52. Summary Slow web performance impacts your business Use performance tools to assess performance Start optimizing front end performance first 34 best practices for optimizing web sites
53. Thank you! Ken Liu @kenliu (Twitter) k.a.liu@ieee.org