harlan-zw/nuxt-delay-hydration

Status: Stable v2 v0 ✅ , v3 main ✅ Made possible by my Sponsor Program 💖 Follow me @harlan_zw 🐦

⚠️ This is a "hack" to trick Google Lighthouse into thinking your site is faster than it otherwise would be.

• It should only ever be used for progressively enhanced websites.
• It may not provide any real performance or SEO benefit (test it with CrUX, not Google Lighthouse).

Features

• 🔥 Reduce your sites "Blocking Time"
• 🚦 Filter it to run only on specific pages
• 🍃 Minimal config
• 🔁 (optional) Replay pre-hydration clicks

Install

If you're using Nuxt 2.x, please follow the docs on the v0 branch.

yarn add -D nuxt-delay-hydration
# npm i -D nuxt-delay-hydration
# pnpm add -D nuxt-delay-hydration

Requirement: Progressively enhanced SSR or SSG Nuxt app.

Usage

// nuxt.config.ts
export default {
  modules: [
    'nuxt-delay-hydration',
  ],
  delayHydration: {
    // enables nuxt-delay-hydration in dev mode for testing
    debug: process.env.NODE_ENV === 'development'
  }
}

Note: The module will not run in development unless you have enabled debug.

Choosing a mode

By default, no mode is selected, you will need to select how you would the module to work.

Type: init | mount| manual | false

Default: false

Regardless of the mode you choose, please read further optimisations.

Init Mode

This mode delays all scripts from loading until the hydration promise is resolved.

It does this by hooking into the HTML rendering, removing all script tags and adding them back after the hydration promise is resolved.

This will provide the biggest speed improvements however is the riskiest.

Pros: Provides the biggest blocking time reduction

Cons: Risky if you have critical third party scripts

Benchmark: ~90-100% reduction

export default {
  delayHydration: {
    mode: 'init'
  }
}

Mount Mode

This mode delays Nuxt while it's mounting. Plugins and some third-party scripts will work.

This delays your layout and page components.

Pros: Safer and still provides good improvements

Cons: May still break certain layouts if they are js dependent.

Benchmark: ~70% reduction

export default {
  delayHydration: {
    mode: 'mount'
  }
}

Manual Mode

Using the manual mode, you manually specify what part of your app you'd like to delay. Useful for when you need some part of the page to always hydrate immediately, such as a navigation drawer.

Pros: Safest way to optimise

Cons: Speed improvement based on usage

export default {
  delayHydration: {
    mode: 'manual'
  }
}

DelayHydration component

Once you have set the mode, you need to use the component.

<template>
  <div>
    <DelayHydration>
      <div>
        <LazyMyExpensiveComponent />
      </div>
    </DelayHydration>
  </div>
</template>

Guides

Debugging

export default {
  delayHydration: {
    debug: process.env.NODE_ENV === 'development',
  },
}

<template>
  <div>
    <MyHeader />
    <DelayHydration>
      <div>
        <!-- Show the hydration status, only for debugging -->
        <HydrationStatus />
        <main>
          <nuxt />
        </main>
        <my-footer />
      </div>
    </DelayHydration>
  </div>
</template>

Performance Auditing

Use my audit tool: https://unlighthouse.dev/

Replaying hydration click

export default {
  delayHydration: {
    replayClick: true
  },
}

Further Optimisations

Advanced Configuration

Configuration should be provided on the delayHydration key within your Nuxt config.

If you're finding the lab or field data is not performing, you may want to tinker with this advanced configuration.

Filtering routes

Using the include and exclude options, you can specify which routes you'd like to delay hydration on.

// nuxt.config.ts
export default {
  delayHydration: {
    include: [
      '/blog/**',
    ],
    exclude: [
      '/admin/**'
    ],
  },
}

You can provide a glob pattern similar to route rules or a regex.

Event Hydration

hydrateOnEvents

• Type: string[]
• Default: [ 'mousemove', 'scroll', 'keydown', 'click', 'touchstart', 'wheel' ]

Controls which browser events should trigger the hydration to resume. By default, it is quite aggressive to avoid possible user experience issues.

replayClick

• Type: boolean
• Default: false

If the trigger for hydration was a click, you can replay it. Replaying it will re-execute the event when it is presumed your app is hydrated.

For example, if a user clicks a hamburger icon and hydration is required to open the menu, it would replay the click once hydrated.

⚠️ This is experimental, use with caution.

Idle Hydration

idleCallbackTimeout

• Type: number (milliseconds)
• Default: 7000

When waiting for an idle callback, it's possible to define a max amount of time to wait in milliseconds. This is useful when there are a lot of network requests happening.

postIdleTimeout

• Type: { mobile: number, desktop: number } (milliseconds)
• Default: { mobile: 5000, desktop: 4000, }

How many to wait (in milliseconds) after the idle callback before we resume the hydration. This extra timeout is required to avoid the standard "blocking", we need to provide real idle time to lighthouse.

Mobile should always be higher than desktop as the CPU capacity will generally be a lot less than a desktop.

Note: The default will likely be customised in the future based on further benchmarking.

Debugging

debug

• Type: boolean
• Default: false

Log details in the console on when hydration is blocked and when and why it becomes unblocked.

Benchmarks

• Pokemon
• Countries
• Manual

Live examples

• https://www.odysseytraveller.com/
• https://massivemonster.co/

Credits

• Markus Oberlehner. Pioneer of the lazy hydration in Vue

Sponsors

License

MIT License © 2022 - Present Harlan Wilton