Is your feature request related to a problem? Please describe.
This is a re-opening of #157 to ask about the size of db.json in non-full-static apps.
The size of db.json is quite large in universal apps, can can cause noticeable slowdowns on client-side routes. Consider a personal homepage - where no blog content is needed on the main page. But then in a universal app - if the user clicks through to the blog page - it loads a very large db.json file causing a slow client-side navigation. On my personal site with only ~10 blog posts, that file is already 2MB in size, and on a Fast 3G connection, it takes ~1.5 seconds to load. I can only imagine what this file would become on larger sites with potentially hundreds of blog posts.
Describe the solution you'd like
Would it be possible to split the file into multiple chunks and choose the proper chunk to load based on use case? Potentially a smaller manifest file (without full text) to be used as an index on blog post listing page, a file per entry with the full-text to be used on a single blog entry page, and then the full-size db.json for full-text search or other complex use cases? Short of full-text search, this smaller manifest file would be sufficient for most other queries I would assume.
Describe alternatives you've considered
I used to use a similar manual approach but switched to @nuxt/content when it came out - not realizing the performance hit that would come with the large db.json file. The approach I used to take would generate a JSON manifest file from the front-matter of content files as a webpack plugin, then individual pages would load the content through a dynamic import and markdown-loader (thus creating a chunk per content file).
Additional context
This issue at hand can be seen by loading https://brophy.org and clicking through to the Blog page with Dev Tools open.
Is your feature request related to a problem? Please describe.
This is a re-opening of #157 to ask about the size of
db.jsonin non-full-static apps.The size of
db.jsonis quite large in universal apps, can can cause noticeable slowdowns on client-side routes. Consider a personal homepage - where no blog content is needed on the main page. But then in a universal app - if the user clicks through to the blog page - it loads a very largedb.jsonfile causing a slow client-side navigation. On my personal site with only ~10 blog posts, that file is already 2MB in size, and on a Fast 3G connection, it takes ~1.5 seconds to load. I can only imagine what this file would become on larger sites with potentially hundreds of blog posts.Describe the solution you'd like
Would it be possible to split the file into multiple chunks and choose the proper chunk to load based on use case? Potentially a smaller manifest file (without full text) to be used as an index on blog post listing page, a file per entry with the full-text to be used on a single blog entry page, and then the full-size
db.jsonfor full-text search or other complex use cases? Short of full-text search, this smaller manifest file would be sufficient for most other queries I would assume.Describe alternatives you've considered
I used to use a similar manual approach but switched to
@nuxt/contentwhen it came out - not realizing the performance hit that would come with the largedb.jsonfile. The approach I used to take would generate a JSON manifest file from the front-matter of content files as a webpack plugin, then individual pages would load the content through a dynamic import andmarkdown-loader(thus creating a chunk per content file).Additional context
This issue at hand can be seen by loading https://brophy.org and clicking through to the Blog page with Dev Tools open.