The Future Is Fast

Dynamic Apps, Static Files, Unreal Performance

by Jason Lengstorf
@jlengstorf  ·


Hi! I’m Jason Lengstorf.

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

HTML code.
X-Files fan page on Geocities.
Credit: One Terabyte of Kilobyte Age Photo Op

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
Not good enough.

Next came server-side rendering

WordPress PHP code.

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
I will not accept that.

Then we tried client-side rendering

Handlebars code.

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
It wasn’t enough.

We doubled down on client-side rendering

React code.

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
Goalie blocks the goal, but it rolls in behind him while he celebrates.

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

Addy Osmani





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.

Kanye WTF.

Route-based code splitting:

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

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

Summoning Sean Larkin

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?”

Page jumping while images load.


We can fix it!

Lazy loading with loading animation

Lazy loading with animation.

Source: responsive-lazyload.js

Lazy loading with the blur-up technique

Lazy loading with animation.


Lazy loading with traced SVG

Lazy loading with traced SVG.

Source: Gatsby.js

Lazy loading with simplified polygons

Lazy loading with SVG polygons.

Source: Gatsby.js

Service Worker

Service Worker code.

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
Heaviest objects in the universe.

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
Webpack Bundle Analyzer.

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?! 😱

But it’s hard!


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

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


Jason Lengstorf

Jason Lengstorf
@jlengstorf  ·

Tweet: @jlengstorf