September 26, 2015
Making shopify.com fast @ TO Web Performance Group Meetup
Bryson Gilbert presented techniques his team uses on Shopify’s main marketing site, shopify.com
- 10ms goal for generating pages on the server with Ruby on Rails
- no database
- no CMS
- All content is in fast loading, versionable flat files.
- marketing assets (icons, images, css, style guides) are stored in a Ruby gem and shared across different Shopify web properties (admin areas tools, internal tools, blogs etc).
- optimize once, use anywhere
- HTTP requests – in general, each shopify.com page loads 1 common js and css file (shared across all pages), and sometimes 1 page specific js and css file. 3rd party scripts are loaded if needed
- the team is investigating inlining the page specific code – it is usually small, and could save 2 HTTP requests
- some A/B testing tools require blocking js to manipulate copy and images before gathering results. This sucks, but there is no choice
- load as much 3rd party JS asynchronously as possible
- lazy load images with lazysizes
- responsive images – using a Ruby gem to make implementing img srcset attribute and lazy image loading easier across all web properties
- icons – using inline .svg, no icon fonts
- workflow – set up a Git precommit hook to run imageOptim on images so that unoptimized images never even get into the Git repo
- fonts – just using @font-face, no inlining
- just serving woff and woff2, best file size and adequate browser support for their audience (people on slow connections also tend to have browsers that don’t support woff, so they don’t get help up downloading fonts)
- not optimized yet.
- this is the hackiest part of optimization
- going HTTPS only did slow down the site slightly
- SpeedCurve for monitoring performance, relating deploys to changes in performance
- NewRelic RUM for checking on performance around the world.
- Shopify is getting into Performance Budgeting by setting relative goals.
- HTTP2 will change how pages are optimized
- resource hints will be helpful, but not 100% controllable
- Better font loading is coming
Building a culture of performance
- Sharing knowledge with documentation
- Weekly frontend dev meetings to discuss failures & successes
- Working performance into discussions early on in design process (can help with photo/image selection)
Other fun stuff (some from Barbara’s new book)
- Etsy publishes quarterly website performance reviews
- Performance is respect for users. Optimized for their perspective, not your s. Real User Monitoring.
- think about the 14kb rule
- use inline CSS for above the fold content
- loads js as late as possible
- Latency on mobile – remember cell phones have to initiate a connection to a cell phone tower that is rarely a consistent distance away.
- JS and AJAX eat mobile batteries fast