performance/bundle-size

11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Tree-shakable Vue APIs

Many of Vue's APIs are tree-shakable if bundled via a modern build tool. For example, if you don't use the built-in Transition component, it won't be included in the final production bundle. Tree-shaking can also remove other unused modules in your source code.

JavaScript savings from pre-compiling templates

When using a build step, templates are pre-compiled so the Vue compiler does not need to be shipped to the browser. This saves 14kb min+gzipped JavaScript and avoids the runtime compilation cost.

Choosing tree-shaking friendly dependencies

When using a build step, prefer dependencies that offer ES module formats and are tree-shaking friendly. For example, prefer lodash-es over lodash. Use tools like bundlejs.com for quick size checks, but measuring with your actual build setup will always be the most accurate.

Using petite-vue for progressive enhancement

If you are using Vue primarily for progressive enhancement and prefer to avoid a build step, consider using petite-vue (only 6kb) instead of the full Vue build.

Global registration prevents tree-shaking of unused components

A drawback of global registration is that build systems cannot remove unused components (tree-shaking). If a component is globally registered but not used anywhere in the app, it will still be included in the final bundle, increasing bundle size unnecessarily.

Composition API produces smaller production bundles

Code written in Composition API with <script setup> is more efficient and minification-friendly than Options API. The template is compiled as a function inlined in the same scope of the script setup code. Unlike property access from 'this', the template code directly accesses variables declared in <script setup> without an instance proxy, leading to better minification because variable names can be safely shortened.

Vue custom elements bundle size considerations

Vue custom elements have a ~16kb baseline size cost depending on features used. This makes Vue not ideal for shipping a single custom element - vanilla JavaScript, petite-vue, or small-runtime frameworks may be better choices. However, the base size is justifiable when shipping collections of custom elements with complex logic, as Vue allows each component to be authored with less code. The more elements shipped together, the better the trade-off.

Externalizing Vue from custom elements bundle

If custom elements will be used in an application also using Vue, you can externalize Vue from the built bundle so the elements use the same copy of Vue from the host application. This reduces overall bundle size.

Runtime-only builds vs full builds

Build files that start with 'vue.runtime.*' are runtime-only builds that do not include the compiler—all templates must be pre-compiled via a build step. Build files that do not include '.runtime' are full builds that include the compiler and support compiling templates directly in the browser, but increase the payload by approximately 14kb.

Default tooling uses runtime-only builds

Default Vue tooling setups use the runtime-only build since all templates in SFCs are pre-compiled.

In-browser template compilation with build step

If you need in-browser template compilation even with a build step, configure the build tool to alias 'vue' to 'vue/dist/vue.esm-bundler.js' instead.

Give your agent this brain