After packaging, the local search index js file exceeds 500kb.
you-hengh opened this issue · comments
Describe the bug
After using the packaging command, the prompt
Some chunks are larger than 500 kB after minification
I checked the generated file and found that the @localSearchIndexroot.DwawiV-k.js
file was too large, more than 800 kb.
Reproduction
Executing the build command will result in chunks exceeding 500kb
Expected behavior
How to keep chunks from exceeding 500kb or solve the source problem. The index file seems to be too large.
I will provide an index file produced by me in the attachment.
System Info
System:
OS: Windows 11 10.0.22631
CPU: (20) x64 13th Gen Intel(R) CoreT i7-13800H
Memory: 17.23 GB / 31.74 GB
Binaries:
Node: 20.11.1 - ~\AppData\Local\pnpm\node.EXE
npm: 10.2.4 - ~\AppData\Local\pnpm\npm.CMD
pnpm: 8.15.4 - ~\AppData\Local\pnpm\pnpm.EXE
Browsers:
Edge: Chromium (122.0.2365.52)
Internet Explorer: 11.0.22621.1
npmPackages:
vitepress: ^1.1.3 => 1.1.3
Additional context
@localSearchIndexroot.DwawiV-k.zip
Validations
- Check if you're on the latest VitePress version.
- Follow our Code of Conduct
- Read the docs.
- Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
You probably have a big site. You can reduce it to some extent by adding search: false
to your CHANGELOG.md's frontmatter (that is getting unnecessary indexed, or maybe add it to srcExclude in vitepress config if you don't want to render it at all). But other than that I don't think there is currently any way to split this chunk.
Also, I would recommend verifying if your host has brotli compression enabled. With brotli, the network requests will be around ~240 KB for end users and verify if the assets have proper cache headers -- things inside assets directory are fingerprinted, so you can use Cache-Control: max-age=31536000, immutable
there.
This chunk is lazy loaded and won't affect initial load for users. You can verify if it's fast enough by deploying and trying out searching. If it's working fine you can probably ignore that warning or adjust warning limit till it goes to 2 MB or something.
You probably have a big site. You can reduce it to some extent by adding
search: false
to your CHANGELOG.md's frontmatter (that is getting unnecessary indexed, or maybe add it to srcExclude in vitepress config if you don't want to render it at all). But other than that I don't think there is currently any way to split this chunk.Also, I would recommend verifying if your host has brotli compression enabled. With brotli, the network requests will be around ~240 KB for end users and verify if the assets have proper cache headers -- things inside assets directory are fingerprinted, so you can use
Cache-Control: max-age=31536000, immutable
there.This chunk is lazy loaded and won't affect initial load for users. You can verify if it's fast enough by deploying and trying out searching. If it's working fine you can probably ignore that warning or adjust warning limit till it goes to 2 MB or something.
I deleted the CHANGELOG.md file, deleted the cache and dist folders, rebuilt the program, but still prompted
Some chunks are larger than 500 kB after minification.
And @localSearchIndexroot. DwawiV-k.js
files have not been significantly reduced, just from 882kb to 824kb
My host uses nginx as a proxy, the compression method used is gzip, I tried to use brotli compression, but installing this brotli was too complicated, and eventually I gave up using brotli.
If vitepress can't fix the oversized @localSearchIndexroot. DwawiV-k.js
file, I have no better choice but to ignore this warning (changing the size of 500kb doesn't really solve the problem, does it?)
changing the size of 500kb doesn't really solve the problem, does it?
yeah it just suppresses the warning.
Can you share the output of this command from PowerShell in your docs folder:
Get-ChildItem –Path "*.md" -Recurse | Get-Content | Measure-Object -Character -Line -Word