-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Large Build Size #1607
Comments
The reason every shared CSS and JS is included in every page, is because users can start navigating the site starting from any arbitrary page on the website. Despite this, most CSS and JS are cached, so only the first page loads ~2.5mb over the network, afterwards it uses the cache. Another potentially large contributer might be a large explorer list (so many pages). These are also cached however. If you want to reduce the bundle size, disable feature you don't use. For example, Katex uses about ~800kb (or 1/3 of the bundle size.) If you don't use this, it will save you a bit of bundle size. Can you please verify that navigating between pages uses the cache? If it doesn't, that would require a change or fix to the caching policy. |
I'm a bit confused about how that works. If the content (HTML, JS) is bundled into a single file(except fonts, css and few js scripts), how does caching would work only some of the data inside that file? And whenever i navigate between file it does fetch entire content including duplication of many js bundles. Additionally, regarding unused features: I already disabled KaTeX, but this didn't affect the overall bundle size. On inspecting the HTML, I noticed the KaTeX library's code is still bundled into every HTML file. |
There is very few inlined JS/CSS. And yes, the other files ( As for the KaTeX part, do you mind sharing your |
this is my config and it's deployed on https://logs.anokha.me. and it fetch 700kb(compressed version of 2.5mb) of html on every page load which is a lot i think
|
ah the increase in bundle size is due to the recent support for mermaid (in which we dump the JS onto the final HTML files #1575) we can probably update the emitter to dump you can check with fwiw you can use rehypeMermaid, but it involves setting up playwright, in which I think probably not good for default Quartz. Best solution is to have a plugin system (Eh I will get to it sometime this holiday szn lol) so we can done all of this beforehand, eliminating any sort of need for inline JS bundling. |
thanks for the insight, @aarnphm removing mermaid did the trick—my build size has dropped back to normal. appreciate the suggestion, and looking forward to this in plugin system when you get around to it |
For other folks who just need to know what to change in Search for the Plugin.ObsidianFlavoredMarkdown({ enableInHtmlEmbed: false, mermaid: false }), |
Disabling mermaid did the trick for me also. |
I removed the graph component from my setup for a further pagespeed boost. See my blog post https://vxlabs.com/2024/11/23/speed-up-obsidian-quartz-page-loads/ for details about what I did, and what the contributions wnere of mermaid.js and the graph component. |
There is a solution for this. To separate out mermaid components and dump the inline into postscript.js but currently not ideal. |
Each HTML file currently averages a size of 2.5MB, likely due to repetitive inclusion of CSS/JS files. Could we explore separating these resources to reduce redundancy?
The text was updated successfully, but these errors were encountered: