Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Making Grails Web Sites Fast

Making Grails Web Sites Fast

Front end performance optimization with Grails
GR8Conf US 2013

Ken Liu

July 23, 2013
Tweet

More Decks by Ken Liu

Other Decks in Programming

Transcript

  1. About me Web development with Java since JDK 1.0.2 (applets,

    anyone?) Groovy and Grails since 2009 Lead developer for IEEE Spectrum
  2. 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
  3. Agenda Why focus on web performance? How to assess website

    performance Tools and techniques for improving performance Grails plugins for web performance
  4. Agenda Why focus on web performance? How to assess website

    performance Tools and techniques for improving performance Grails plugins for web performance
  5. 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
  6. What makes websites slow? Slow server performance Network latency Heavyweight/unoptimized

    web pages Third-party social network widgets and beacons Ad serving China firewall
  7. Agenda Why focus on web performance? How to assess website

    performance Tools and techniques for improving performance Grails plugins for web performance
  8. 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
  9. The Performance Golden Rule “80-90% of the end-user response time

    is spent on the frontend. Start there.” - Steve Souders
  10. 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/
  11. 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
  12. Agenda Why focus on web performance? How to measure website

    performance Tools and techniques for improving performance Grails plugins for web performance
  13. “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
  14. 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/
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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)
  20. 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)
  21. 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
  22. 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
  23. 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
  24. 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
  25. Image spriting Don’t do image slicing! Combine tiny icons/graphics into

    “sprite sheet” Downsides - maintenance, retina support
  26. 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
  27. HTML5/CSS3 techniques Use CSS3 rounded corners, drop shadows, gradients, not

    images Old browsers get degraded, but functional, appearance
  28. 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
  29. Agenda Why focus on web performance? How to measure website

    performance Tools and techniques for improving performance Grails plugins for web performance
  30. UiPerformance plugin Granddaddy of all web performance plugins “Swiss Army

    knife” approach No longer maintained, replaced with Resources plugin family
  31. 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?
  32. 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
  33. 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
  34. 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
  35. 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!
  36. 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
  37. 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
  38. Zipped resources plugin Automatically gzips static resources and caches in

    server May be better/easier just to set gzip at web server
  39. 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
  40. 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
  41. 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/
  42. 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