Nuxt.js: Nuxt Performances: Present and Future

[Atinux]

On top of letting your write Vue files, creating pages with the filesystem and managing your SEO with vue-meta, the NuxtJS team and contributors worked a lot of shipping by default an efficient and performant web application.

What do we have today:

• Route based chunking
• Auto preload/prefetch links
• Webpack 4: Tree Shaking, Code splitting, Terser, Hahsed file names optimized for long-term caching, Optimistic Chunk Groups, Optional CSS Extraction
• HTTP/2 push headers support
• Server-Timing header
• PWA/Workbox Module — lighthouse 100 score by adding a single module!
• AMP Support
• Modern Mode to serve less-transpiled bundles to modern browsers with nuxt build —-modern
• Smart placeholder to avoid extra loads to Nuxt rendering
• nuxt-start for production (8MB install vs 60MB with nuxt)
• Bundle analyzer with nuxt build —analyze
• Minify HTML
• ETAG
• nuxt-ssr-cache module
• SPA server cache
• HTTP Compression
• Dynamically prefech links/scripts/components is inspired by quicklink
• Guess.js support
• TypeScript Support
• Webfont Loader
• Lazy Hydration

What do we plan to do:

• Webpack 5 support
• Reducing initial bundle size
  
  
  
  • Nuxt starter app could be a simple app.vue file (including only vue and vue-meta)
  
  
  • Vue3 Support
  
  
  • Select features individually to reduce bundle sizes (experimental)
  
  
• Smart SSR Module (stale-while-revalidate cache aka SPR and dynamic SSR/SPA switching)
• Multi target builds (static, server, serverless)
  
  
  
  • Full static support
  
  
• Lamba API Support
• CI/CD for continues performance measurements (for PRs to the core)
• Critical CSS extraction
• Image Module (lazy-loading and size-optimize)
• Supporting APP Shell (SSR only for layout)
• In discussion: Rewrite core in typescript

How to accomplish this:

Maintaining an open source project requires consistent effort, not just with adding code, but also code reviews and support. The NuxtJS team and contributors coordinates their efforts on Discord. We all work on our free time to maintain it and I do believe the Chrome Performance Fund could help us to pay ourselves and our contributors on this future work thanks to our Open Collective.

[Niputi]

https://github.com/maoberlehner/vue-lazy-hydration
should maybe also be added to the "What do we have today"

[Atinux]

Will update thank you @Niputi

[addyosmani]

We all work on our free time to maintain it and I do believe the Chrome Performance Fund could help us to pay ourselves and our contributors on this future work thanks to our Open Collective.

I'm happy to share Chrome is donating $12,000 to support Web Performance optimizations on the Nuxt.js roadmap 🎉 We think this project's goals align well with helping reduce the initial bundle size of modern web experiences, like those built with Vue.

In particular, we're excited to see the project explore the proposed work on:

• Reducing the baseline bundle costs for the Nuxt starter app
• Image bloat reduction (via lazy-loading and better optimization)
• Work on smarter SSR using SWR (stale-while-revalidate)

We know the work to upgrade to Webpack 5 has been a long one and are looking forward to seeing those changes land too! We hope this funding helps support your work just a little :)

~ signed Addy, @stubbornella and @spanicker

[galvez]

Work on smarter SSR using SWR

The term SWR is new to me. Can you clarify?

[addyosmani]

SWR = stale-while-revalidate :)

[galvez]

@addyosmani ah gotcha, thank you :)

[assoft]

This is great news

[shadow81627]

https://github.com/bazzite/nuxt-optimized-images
Automatically optimizes images used in Nuxt.js projects

Does this cover size-optimize for the Image Module?

[Atinux]

Actually, the nuxt-optimized-images handles the resize but it’s handled in Webpack directly, we also want to provide a system where your images are external or in the static directory :)

[axetroy]

Can you consider reducing the size of nuxt in the production environment?

I found that when using Docker to package images, even in a production environment, the size is 400 ~ 500M, which is a waste of resources

Is it possible to consider compiling into a single Javascript file so that the user can further reduce the size by some tool. eg. webpack/ncc

So users can run the application by running the following command

> nuxt build
> cd ./dist
> ls -lh
total 44040192
-rw-r--r--    1 root  staff   44040192B 12 29 13:45 index.js
> node ./index.js
Listen on port 3000

I hope the final production environment file is ideal in the size of ~400-500M~ 20-50 M

[danielroe]

@axetroy Have you tried using nuxt-start?

[axetroy]

@danielroe
It has nothing to do with the situation I describe

[danielroe]

@axetroy I've spent some time slimming Nuxt Docker images, and nuxt-start is a key ingredient.

If you are starting Nuxt programmatically, you could try listing just @nuxt/core in your dependencies and adding any additional ones as needed, such as vue-meta, etc. You might also find you don't need to include buildModules in your prod build, and I highly recommend configuring yarn autoclean.

The issue you highlight is, I think, not an issue with Nuxt per se but in the nature of node_modules-based projects. ncc is a good solution. With now-builder, for example, it's routine to create 10-20Mb Nuxt lambdas. I am following this PR with interest as the serverless target has the potential to deliver the kind of build you're probably looking for.

[dsonet]

Can you consider reducing the size of nuxt in the production environment?

I found that when using Docker to package images, even in a production environment, the size is 400 ~ 500M, which is a waste of resources

Is it possible to consider compiling into a single Javascript file so that the user can further reduce the size by some tool. eg. webpack/ncc

So users can run the application by running the following command

> nuxt build
> cd ./dist
> ls -lh
total 44040192
-rw-r--r--    1 root  staff   44040192B 12 29 13:45 index.js
> node ./index.js
Listen on port 3000

I hope the final production environment file is ideal in the size of ~400-500M~ 20-50 M

Sounds like Yarn v2 does what you wanted.

[irvv17]

I LOVE NUXTJS!

[mirkosaugo]

hi @Atinux, i want to suggest also this optimization for the future: https://develoger.com/how-to-obfuscate-css-class-names-with-react-and-webpack-20e2b5c49cda

[MarvinMiles]

@mirkosaugo
https://github.com/google/postcss-rename
https://nuxtjs.org/faq/postcss-plugins/

[mirkosaugo]

/* ** Build configuration */ build: { extractCSS: true, postcss: { plugins: { 'postcss-rename': { strategy: "minimal", by: "part", outputMapCallback: (a) => { console.log(a); } }, } } }

Okay @MarvinMiles this works, but only in css files ... what about class names in the html files?

[J05HI]

@MarvinMiles @mirkosaugo
It doesn't work for me. Only CSS gets replaced.
I'm using Tailwind btw.

[hoektoe]

Also looking for tailwind config with nuxtjs

[dario-valles]

Just discovered snowpack, as they say:

Snowpack is your near-instant web build tool. Snowpack replaces your dev bundler with a dev environment that only builds files as they are requested by the browser. That means instant dev startup times, less unnecessary work and faster updates on every save.

When you're ready to deploy your site, Snowpack automatically optimizes and bundles your site for production.

It could be a good replacement, in a near future it will increase develop time a lot

[HunderlineK]

@dario-valles Would Vite be an alternative to snopack?

[dzcpy]

This is definately a good start. Nuxt is significantly slower than Next, which shouldn't be. I hope with all these new features implemented, Nuxt could be faster than Next one day!

[Atinux]

@dzcpy could you give more informations in what area Nuxt is slower than Next?

[dzcpy]

@Atinux I personally tested using Apache Bench, with an empty project.
https://cnodejs.org/topic/5e0c53b801c0915a9d9bd697#5e11f2a14bea432607fccee7
Someone else made a similar benchmark and it's even worse (190/s vs 928/s):
https://nodesource.com/blog/next-nuxt-nest/
There is a huge performance improvement in a recent Next version, maybe that's why.

[MrJmpl3]

@Atinux , please don't forget the nuxtClientInit, https://github.com/nuxt/nuxt.js/issues/240

[manniL]

@Atinux , please don't forget the nuxtClientInit, #240

You can already "mimic" such a behavior using a client-side Nuxt plugin 😋

[sanket143]

https://github.com/vuejs/rfcs/issues/183

  if (isTrue("I am the author of a Vue ecosystem library")) {
    // It's time to make your lib Vue 3 compatible!
    return
  }

Yayyy, :smiley: Has nuxt.js already up for Vue 3? maybe now is the time.

[manniL]

@sanket143 check https://github.com/nuxt/nuxt.js/issues/5708

[pxwee5]

Can we have an option to disable Vuex? For many marketing websites, Vuex is unnecessary and can be replaced by Vue.observable. Saving those 5KB gzip goes a looong way for Lighthouse performance.

[danielroe]

@pxwee5 This exists. See https://github.com/nuxt/nuxt.js/pull/6287

[mlops]

snowpack with nuxt.

[gaven]

According to a tweet by @yyx990803 - it seems as though partial hydration could be feasible in Nuxt with the adoption of Vue 3. Id love to see this become a core part of Nuxt. Are there any internal conversations happening around this idea? I'd be happy to do some initial work to get this off the ground 🚀 Thanks!

Tweet Reference: https://twitter.com/youyuxi/status/1270032102097068037

[MaazDev]

Any news about Rewriting nuxt core in typescript ? still marked as in discussion ?

[Atinux]

We are already rewriting Nuxt 3 in TypeScript :)

[AlexFromJraft]

@Atinux is there a roadmap/RFC for Nuxt 3/plans for how the community can contribute?

[Atinux]

At the moment it is still in private mode since it is a proof of concept, as soon as we have an alpha we will open it and the roadmap will be public with guide to contribute.

Thank you very much for your motivation to help us <3

[happynautpro]

@Atinux Are there any concrete plans to introduce incremental builds like next.js has done it? Seems like a very welcome feature ;) https://github.com/nuxt/nuxt.js/issues/6138

[Atinux]

@happynautpro you are talking about incremental static generation?
This could be done with a module setting caching headers for pages directly, Pooya has been working on a module for that: https://github.com/pi0/nuxt-swr-cache

[happynautpro]

@Atinux yes I’m talking about incremental static generation but I guess the module doesn’t solve the problem. I’m looking for a solution to generate only routes which are changed or a new instead of deploying a whole static site from zero, each time there is only a content change.

Use case would be: Imagine of a site with 1M pages and static hosting (no SSR runtime). In the current scenario, you have to deploy all 1M pages again, if there is only one mirror content change (I’m not talking about code changes). Wouldn’t it be smarter to deploy only the route again, where the content has changed?

[AlexFromJraft]

@happynautpro @Atinux

I totally agree that incremental static generation should be a feature should be on the roadmap for the nuxt team going on in the future, but providing a generic incremental build feature may be hard for the Nuxt team to implement themselves as Nuxt currently cannot know the relationships between each piece of data and the pages at build time.

Gatsby solves this problem by forcing the user to fetch data via GraphQL, with GraphQL then defining a query that describes the data needed letting Gatsby know what pages need to be rebuilt whenever specific data is changed.

With that being said, talk about this feature might be better discussed in the GraphQL module for Nuxt, as this is a feature that kind of lies inbetween nuxt core and the nuxt GraphQL module which puts the core team in a weird spot if they were to develop this.

Maybe the solution is a module that interfaces with Nuxt's community Apollo Module? I really do not know, but then we'd be looking at modules for modules which i'm not even sure would be possible (or preferable)

[shadow81627]

Could the @nuxt/content module use something like the build cache but for filtering the files that need to be generated? If only one file in the /content folder has change only the html files that use it get regenerated?

[patrickcate]

Image Module (lazy-loading and size-optimize)

Any update of this feature?

[shadow81627]

@patrickcate There is a work in progress nuxt image module