Closed Mister-Hope closed 5 months ago
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
packages/bundler-vite/src/build/resolvePageChunkFiles.ts | 0 | 1 | 0.0% | ||
packages/cli/src/commands/dev/handlePageUnlink.ts | 0 | 1 | 0.0% | ||
packages/client/src/composables/siteData.ts | 0 | 1 | 0.0% | ||
packages/client/src/setupGlobalComponents.ts | 0 | 1 | 0.0% | ||
packages/cli/src/commands/dev/handlePageAdd.ts | 0 | 2 | 0.0% | ||
packages/cli/src/commands/dev/handlePageChange.ts | 0 | 2 | 0.0% | ||
packages/client/src/composables/routes.ts | 0 | 2 | 0.0% | ||
packages/core/src/app/appPrepare.ts | 0 | 2 | 0.0% | ||
packages/core/src/app/prepare/preparePageChunk.ts | 1 | 3 | 33.33% | ||
packages/client/src/router/resolveRoute.ts | 0 | 4 | 0.0% | ||
<!-- | Total: | 21 | 101 | 20.79% | --> |
Totals | |
---|---|
Change from base Build 7670827817: | -0.4% |
Covered Lines: | 675 |
Relevant Lines: | 1716 |
perf: implement custom routes
BREAKING CHANGE: vue-router's route records have been replaced by custom route records to get better performance. It should not break common usage, but could be a potential breaking change for some themes. vue-router is suitable for SPAs, but not for static sites. It has a negative impact on the performance of vuepress sites, especially large-scale ones. In the long run we'll replace vue-router with a light-weighted custom router totally, but we'll try to keep the compatibility for sure.
LGTM
LGTM
Description
This pr reduces output size and improves performance at the same time.
Including:
merging page data and component into 1 chunk
Usually page data chunk is small (<1kb), and with
shouldPreload
shouldPrefetch
and HTTP1.1, it will affect network. Merging them to 1 chunk almost reduce half of the chunk amount. And do not have negetive influencea as they are always fetch together.avoid heavy operation with
router.resolve
router.resolve
performsRegExp.exec()
when mapping the whole routes array to find a matched result.To solve this, we introduce:
hasPage
(repalcement of detecting whether a route exisits)getPagePaths
(replacement ofroutes.getRoutes
)To align
route
changes withpageData
, we exec page component and page data fetching inbeforeResolve
hook, which means everyrouter.resolve
(so is<RouterLink>
) actually fetchs that page component and data and parse them.To solve this, we introduce:
<VPLink>
component which is "light"resolve
helper (replacement ofrouter.resolve
to get path and meta data)Removing duplicated route records with redirects and maps holding data, components
Now a single map holds all pages info and pageKey and a redirection map are used at client:
Breaking changes
pageKey is removed at client, so operations like
router.push(pageKey)
router.resolve(pageKey)
no longer workrouteMeta
is renamed tometa
We want to decouple meta concept with router
routeMeta
is deprecated but still supported for backwards compatibility, we should remove the support in stable.dataFileChunkName
dataFilePath
anddataFilePathRelative
are renamed tochunkName
chunkFilePath
andchunkFilePathRelative
New Recommendations
People should use
resolve
in@vuepress/client
to get page metaGetting page meta with
router.resolve
is deprecated but still supported for backwards compatibility, we should remove the support in stable. (We can support this for sure, but I think that decouple meta with routes could be better)Note: Calling
router.resolve
to get a correct page path is still supported as this is a correct usage. (but since it's heavy, maybe we should warn users to useresolve
as first choice)People should use
<VPLink>
as first choice then<RouterLink>
In these cases, they should use
<VPLink>
as the cost of it is 90% less than<RouterLink>
Other notes
To support clean url (e.g.: navigating to
/a/b
and resolve/a/b.html
to/a/b
), we improved generation ofhtmlRelativePath
andhtmlPath
on Page objectBenchmark
Ci result while finishing official docs page-render stage:
Local test result with a 1 million words project https://innenu.com/:
RFC
BTW, if we drop markdown link support, we can have higher performance.
I would upvote to drop support for markdown links, since we already convert every markdown link in markdown files to
<VPLink>
with.html
suffix.What do you think if we add a router field in config files with options like: