# Nuxt Booster: a Nuxt module that stops the page loading what it cannot see > Nuxt Booster takes over the Lighthouse performance work of a generated Nuxt site, loading components, fonts, images and iframes only when they enter the viewport, and it adds an optional layer that blocks JavaScript until the first performance measurement is done. It targets Node 19 and Nuxt 3.5 or newer, and the module still works in Internet Explorer 11. **basics/nuxt-booster** — nuxt-booster will help you to improve the lighthouse performance score (100/100) of your website. 🚀 - Repository: https://github.com/basics/nuxt-booster - Website: https://basics.github.io/nuxt-booster/ - Stars: 866 · Forks: 37 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/basics-nuxt-booster ## What the module claims to take over The one-line description is that Nuxt Booster takes over the Lighthouse performance optimization of your generated website, and the mechanism is stated plainly: all used components and resources are loaded on demand based on the viewport. The claim that follows is specific: delivery of the minimum required resources based on the current viewport, and that if you use the tools as specified you will get a Lighthouse performance score of 100/100. A module that rewrites loading behaviour across a whole site is a substantial intervention rather than a plugin, and the repository is sized accordingly, with a src directory, a playground directory for the demo site, a docs directory published with VitePress, and a test directory that generates a test site before running the unit tests. The licence is MIT and the author is Stephan Gerbeth, with Thorn-Welf Walli listed as a contributor. ## Nine features and what each one changes The feature list is the clearest description of the module's scope. There is dynamic loading of viewport-based page resources such as fonts, components, pictures, images and iframes, and a rule that prevents the loading of unnecessary resources, including components, outside the current viewport. There is optional blocking of JavaScript execution by initial performance measuring, and an optimised initial load of JavaScript files by eliminating the unnecessary ones. There is a completely new approach of font declaration, an optimised picture component that supports viewport-based sources such as landscape and portrait, and an optimised image component. There is support for an SEO-friendly lazy hydration mode for picture and image, an optimised YouTube and Vimeo component that auto-generates a poster image in different resolutions, and an optional info layer concept to inform users about a reduced experience when bandwidth or hardware is compromised. ## Blocking JavaScript until the first measurement The most aggressive option in the list is optional blocking of JavaScript execution by initial performance measuring. The reasoning is that a Lighthouse run measures how fast the page becomes usable, and a page that starts streaming a large JavaScript bundle before it has painted will score badly no matter how good the rest is. So the module can hold the scripts back until an initial measurement has been taken, which lets the content paint first. The trade-off is obvious and the module leaves it to you, because the feature is optional. The related info layer idea is the compensation mechanism: when bandwidth or hardware is compromised, the user gets told that the experience is reduced rather than being left to infer it from a slow page. That is a design choice worth noting, since most performance work simply makes the page slower for everyone on a bad connection. ## The font and media components it replaces Two of the features mean the module expects to supply its own components rather than only add behaviour to yours. The font declaration approach is described as completely new, which in context means fonts are declared so that they load when they are actually needed rather than when the stylesheet is parsed. The optimised picture component supports viewport-based sources, so a picture element can offer a landscape asset and a portrait asset and let the browser pick. The optimised image component is the plain equivalent for images. The YouTube and Vimeo component auto-generates a poster image in different resolutions, which addresses the usual problem of a single large preview image for an embedded player. If you already use a specific picture or image component, this is where the migration work sits, and it is the reason to read the documentation before enabling anything. ## Lazy hydration and the SEO caveat The SEO-friendly lazy hydration mode is listed as supporting the picture and image components, and the word doing the work is friendly. Hydration is the step where Vue takes over server-rendered markup and attaches the event handlers, and it is expensive on a page with many interactive elements. Lazy hydration defers that work, which is good for the performance score and potentially bad for search engines that execute JavaScript to see the page, hence the qualifier that the mode is described as SEO-friendly rather than simply lazy. The module also has a preview environment hosted with VitePress documentation, and a playground directory in the repository that serves as the live demo, so you can look at the behaviour before you commit to it. ## Requirements, browser support and the IE11 claim The requirements are NodeJS 19 or newer and NuxtJS 3.5.0 or newer, which is a recent floor for a module targeting Nuxt 3. The browser support table is the notable part. The README states that you can use nuxt-booster with Internet Explorer 11 browser, with a link to a caveats page on browser compatibility, and the table lists IE and Edge, Firefox, Chrome, Safari, iOS Safari, Samsung Internet, Opera and Vivaldi. Shipping viewport-dependent loading that still works in Internet Explorer 11 is a constraint on the implementation, since that is the browser with no support for the modern loading primitives, and it tells you the module has to fall back rather than assume. The link to the caveats page in the documentation is there for the details of what those fallbacks are. ## How the module is developed and tested The package scripts describe a full development setup rather than a library with a thin test suite. The build is driven by nuxt-module-build, with a prepack step that first prepares the playground and then builds the module, and a separate build script that runs nuxt build against the playground. Development uses nuxt dev against the playground or against a separate test project. The test scripts are two-stage: vitest:run first runs nuxt generate on the test directory and then runs the tests, which means the tests exercise a generated site rather than a mocked module, and the unit test target runs against the utils tests specifically. The linting splits into ESLint and Stylelint over the Vue files in src and playground, with a JSON report target, and the documentation has its own VitePress dev and build scripts. ## Running the module against its own playground The development scripts in the package manifest show how the module is exercised against a real site rather than a fixture. Preparing the playground and building the module is a two-part command, and the build script then compiles the playground itself. ```bash nuxt prepare playground && nuxt-module-build build nuxt build playground ``` In development you run nuxt dev against the playground or against the separate test project, and the playground is also what the published preview environment serves, so the same site serves as the demo and the manual test bed. The build artefact that ends up on npm is produced by nuxt-module-build, and the package's exports map points the root import at dist/module.mjs with its types at dist/types.d.mts, so the published package is the module build alone rather than the playground. ## Where Nuxt Booster is the wrong choice Four limits apply. It is a Nuxt module, so it says nothing about the same problem in a plain Vue app or in a framework with its own image component. It changes your component set, since the optimised picture, image, font and video components are the module's own, and a codebase with an established design system will have to reconcile them. It only helps with what it can control, which is the client-side loading of resources below the fold, so a slow origin, an oversized hero image or a render-blocking third-party script will still cost you the score. And the 100/100 claim is conditional on using the tools as specified, which means the work is in adopting them correctly rather than in installing the module, and the preview environment is where you find out whether you did. ## Conclusion Use Nuxt Booster when you have a Nuxt site whose Lighthouse performance score is dragged down by content below the fold, because the module's whole premise is that the browser should not download what the viewport cannot see. Do not expect it to fix every performance problem, since a module that changes what is in the initial payload will not help a slow server response or an oversized hero image. Verify first that you are on Node 19 or newer and Nuxt 3.5.0 or newer, that you are willing to change how your components declare their own resources, since the module replaces your normal image and picture components, and that the preview environment can be used to compare before and after, because a module that changes loading behaviour changes what your users see before it changes what they measure. ## FAQ ### What does Nuxt Booster do? It takes over the Lighthouse performance optimization of your generated Nuxt website, loading components and resources on demand based on the viewport. The stated result is delivery of the minimum required resources for the current viewport, and a 100/100 performance score if you use the tools as specified. ### What are the requirements for Nuxt Booster? NodeJS 19 or newer and NuxtJS 3.5.0 or newer. The module is published under the MIT licence and the latest release is v3.3.2 from 2025-11-22. ### Which components does Nuxt Booster provide? An optimised picture component supporting viewport-based sources such as landscape and portrait, an optimised image component, a new approach to font declaration, and an optimised YouTube and Vimeo component that auto-generates a poster image in different resolutions. It also supports an SEO-friendly lazy hydration mode for picture and image. ### Does Nuxt Booster work in Internet Explorer 11? The README states that you can use nuxt-booster with Internet Explorer 11 and links to a browser compatibility section in the documentation caveats for details. The supported browser table also lists Edge, Firefox, Chrome, Safari, iOS Safari, Samsung Internet, Opera and Vivaldi. ### How are the Nuxt Booster tests run? The vitest:run script first runs nuxt generate on the test directory and then runs the tests, so the suite exercises a generated site rather than a mocked module. There is also a separate unit test target for the utils tests, and linting is split into ESLint and Stylelint over the Vue files. ## Sources - [basics/nuxt-booster on GitHub](https://github.com/basics/nuxt-booster) - [License: MIT](https://github.com/basics/nuxt-booster/blob/main/LICENSE) - [Project website](https://basics.github.io/nuxt-booster/) - [README](https://github.com/basics/nuxt-booster/blob/main/README.md) - [Releases](https://github.com/basics/nuxt-booster/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/basics-nuxt-booster