Performance and bundle size
Understand image cost, layout stability, and measured client-bundle impact.
Photo pages usually spend more bytes on images than JavaScript. Start with correct image delivery, then check the component code your application uses.
Control image cost
- Store accurate dimensions so the browser reserves space before each image loads.
- Use Nuxt Image or prepared
srcsetcandidates for responsive files. - Set
sizesto describe the rendered thumbnail width. - Use
thumbSrcwhen the native path has a separate small thumbnail file. - Keep off-screen images lazy unless they are required for the initial view.
The image delivery concept explains native, Nuxt Image, placeholder, and custom adapter behavior.
Measured client bundle impact
The project measures production consumer builds with Brotli compression. Nuxt results are deltas from the same empty Nuxt application. The values below are from this documentation revision and can change as dependencies or output change.
| Consumer path | Brotli result |
|---|---|
| Nuxt module enabled, no photo component rendered | +1.25 kB |
Nuxt module with one PhotoImage | +1.44 kB |
Nuxt module with one ready-made PhotoAlbum | +27.8 kB |
Vue responsive named import | 657 B |
Vue useLightbox named import | 647 B |
Vue PhotoImage named import | 1022 B |
| Complete Vue package namespace import | 32.1 kB |
PhotoAlbum includes layout, lightbox, gestures, and image behavior. Its number
is the useful comparison for the normal first-album path. A focused lower-level
import is smaller because it does not include those features.
Avoid namespace imports when the application uses only one lower-level utility or component. Nuxt auto-imports ready-made components, so the production bundler can include the code used by the rendered application.
Measure the final application as well. Other modules, route splitting, CSS, image formats, and server settings affect the result users receive.