The Future Is Fast

Dynamic Apps, Static Files, Unreal Performance

by Jason Lengstorf
@jlengstorf  ·  jason@lengstorf.com

Slides: git.io/future-is-fast

Hi! I’m Jason Lengstorf.

• Senior dev / front-end architect
• Occasional designer
• Author & speaker
• Process and efficiency wonk
• Developer relations @ Gatsby
• @jlengstorf on Twitter, Github, etc.

An Incomplete

(and Heavily Biased)

History of the Internet

In the beginning, there was HTML

In some ways it was great:

• Can be hosted cheaply (or free, e.g. on Geocities)
• Supported almost everywhere on the web
• Few requests to display a page
• Typically small file size

In other ways it sucked:

• Lots of copy-pasta
• No such thing as DRY
• Terrible developer experience

Next came server-side rendering

In some ways it was great:

• Separation of concerns!
• Code reusability!
• Dynamic data manipulation!

In other ways it sucked:

• Servers are expensive
• Special hosting required
• Scaling is HARD
• Added complexity

Then we tried client-side rendering

In some ways it was great:

• Keeps most of the benefits of server-side rendering
• No special servers required
• Additional opportunities for interactive UIs

In other ways it sucked:

• Extra requests to load the library
• Interactions are tricky and error-prone
• Requires JavaScript to be enabled

We doubled down on client-side rendering

In some ways it was great:

• Can run full-on apps only in JavaScript
• Interactivity is incredibly approachable
• The community and ecosystem is extensive
• The developer experience is much better

In other ways it sucked:

• We’re sending TONS of JS to the browser
• We still need JavaScript to be enabled
• Pages are loading slooooooooooow

Where we are today

JS Frameworks are powerful

But they’re alsoexpensive

Slow Bloated JavaScript-dependent

53% of visits are abandoned if a mobile site takes longer than 3 seconds to load

Source: Think With Google

So how do we fix it?

To make JS-powered apps really fast, we should:

• Implement route-based code splitting
• Use HTTP/2 to serve assets
• Set up background prefetching
• Lazy load any non-critical assets

You may have heard this called the PRPL Pattern

Addy Osmani
bit.ly/prpl-pattern

To make JS-powered apps really fast, we should:

• Implement route-based code splitting
• Use HTTP/2 to serve assets
• Set up background prefetching
• Lazy load any non-critical assets
• Add a Service Worker
• Eliminate all unused code
• Use server-side rendering to generate static files

That’s a lot of things.

Route-based code splitting:

• Creates smaller bundles for specific routes
• Creates shared bundles for common code
• Allows loading only what’s really needed

Source: Google Developers

Code splitting with Webpack:

• Use import() to identify chunks
• in Webpack 4, use optimization.splitChunks
• In Webpack 3 or earlier, use CommonsChunkPlugin

Totally True Internet Fact

If you say “Webpack” 3 times, Sean Larkin will appear.

Serving assets with HTTP/2:

• Allows multiplexed downloads
• Provides push capabilities to minimize requests

Asset prefetching:

• Assumes which routes the user will load next
• Loads the assets for those routes in the background
• Makes loading the next route almost instantaneous

Lazy loading assets:

• Prevents images from blocking the initial load
• Only requests them once they’re in the viewport

“Won’t lazy loading make the page jump?”

Source: bit.ly/2GayxFF

We can fix it!

Lazy loading with loading animation

Source: responsive-lazyload.js

Lazy loading with the blur-up technique

Source: medium.com

Lazy loading with traced SVG

Source: Gatsby.js

Lazy loading with simplified polygons

Source: Gatsby.js

Service Worker

bit.ly/offline-cookbook

Service Workers:

• Cache critical assets when first installed
• Precache non-critical assets in the background
• Act as a proxy for all outgoing requests
• Skip server & provide cached assets if possible

This allows Progressive Web Apps to
load offline on subsequent visits

Eliminating unused code:

• Reduces the overall size of the codebase
• Helps avoid module bloat

Source: Reddit?

How to remove unused code:

• Use Terser (or Uglify.js) to remove dead code
• Enable tree-shaking with ES modules
• Analyze your bundle output

Source: Webpack Bundle Analyzer

Serving only static assets:

• Removes the need for runtime server rendering
• Eliminates an extra HTTP round-trip
• Improves cacheability

😱 Server-side rendering?! 😱

☹️

Loading 1MB of blocking JavaScript before anything can be displayed

😐

Showing a loading spinner while the framework initializes

😊

Server-side rendering so no JavaScript is required to initially display the page

“But static files won’t work for my app!”

Yes they will. Probably.

Beyond Static

Pre-rendered PWAs

If all of this seems a little overwhelming I totally understand

Performance is hard

We can get most of these performance improvements for free

Open source is awesome. 🎉💕

Gatsby.js does all of thisalready

I migrated my super active blog to @gatsbyjs and think I'm off to a pretty good start 💪 pic.twitter.com/pQwxrbt8Rr

— Mads Obel (@madsobel) May 16, 2018

What is Gatsby.js?

• Framework for building React apps
• Compiles to static files
• Add Service Worker + Web Manifest with plugins
• The developer experience is 👌
• Generated apps are unbelievably fast

Let’s Recap

🔥🔥🔥

Blazing fast apps need fine tuning️

PWA Performance Checklist:

✅ Follow the PRPL Pattern
✅ Add a Service Worker
✅ Remove unused code
✅ Generate static files

Use Gatsby.js to automate perf best practices

(If you want your performance for free)

Pre-Rendered PWAs are the future

...and the future is fast

Thanks!

Jason Lengstorf
@jlengstorf  ·  jason@lengstorf.com