Takes a lot to load

[rostislaved]

Describe the bug

The page feels slow to load. Could you check if there are opportunities to optimize the frontend assets or loading performance?

It takes 2.56 seconds to load every time

What happened?

System information

firefox latest
linux

Where did you encounter the bug?

Public app (sharevb-it-tools.vercel.app)

[sharevb]

Hi @rostislaved , this is probably because of big 13mb asset. I suppose you speak about main page. @0DarkPhoenix, may be you have an idea ? Thanks

[0DarkPhoenix]

I'll try to investigate this on Sunday! That 13mb asset can most likely be the cause, so I'll try to find in localhost what file causes the slowdown.

Also, after loading the website after a long time (like 2 weeks), it gives the following warning on first load. Because of this, it fails to load the website. When you do a normal refresh of the website, this issue doesn't occur anymore and it loads like normal. Maybe this error and the long loading of the homepage are related, because the failure to load is caused by a JS file, which most likely is the same JS file as the 13mb asset.

[0DarkPhoenix]

From what I can see for now, it spends the most time on initializing the Vue application. The two seconds loading time is consistent across all pages, so that seems to confirm that initizaliation is the bottleneck.

The promise callback takes 2.029 seconds, so this matches the 2 second loading time exactly. This promise callback includes the initialization of Vue among other processes, so I'll also try to identify what those other processes are.

I'll look into the code on Sunday, but for now I suspect the following:

• Unoptimized process/unnecessary load for mounting Vue application
• (Maybe) Unoptimal build settings for production build

[sharevb]

Hi @0DarkPhoenix many thanks for this pre analyze (I must admit that I am not expert at this kind for thing). It may also be

it-tools/src/pages/Home.page.vue

Line 16 in 87f7604

const remoteCustomHomeMarkdownResponse = await fetch(`${base}home.custom.md`);

or

it-tools/src/main.ts

Line 44 in 87f7604

const remoteSettingsResponse = await fetch(`${base}tools-settings.json`);

Regarding warning on sharevb-it-tools.vercel.app, this is probably due to the fact that I cannot make PWA preload JS (else Vercel 100GB download quota will to be very very quickly overwhelmed). I don't know how to do better.

it-tools/vite.config.ts

Line 67 in 87f7604

globPatterns: (process.env.VITE_VERCEL_DEPLOY ? ['**\/*.{css,html}'] : ['**\/*.{js,wasm,css,html}']),

Regarding sharevb-it-tools.vercel.app, I now added JS minify (that I disabled because of failure on Vercel build, now handled by GitHub Workflows directly)

@rostislaved if I look at your screenshot, you are on a self hosted (localhost:9001) ? On which page ? Main page ? Some tools have very large dependencies

[rostislaved]

@sharevb Yes, it is a selfhosted it-tools running in Docker.

And yes, the screenshot shows the main page.

[0DarkPhoenix]

I'm sorry for reacting this late, but I didn't have time last Sunday to work on this issue. I'm currently in a demanding period with school next to my job, so I didn't have the time to work on this too. I hope to look into it somewhere this week, but I can't promise anything for now

[sharevb]

@0DarkPhoenix no problem, I asked you because you understand Vite/Vue much better than me. I will take a look this week-end. In the meanwhile, may the force be with you (my english is weak)

[sharevb]

@0DarkPhoenix (and @rostislaved ), for now, I suspect i18n plugin to load all translations of all languages (and that is probably what take the much time). Will investigate further later.

[mathys-lopinto]

I have migrate today my local instance from the original to this fork and i have the same feedback.

This fork take more time to render the primary webpage and load the module

Here the firefox recording of the fork (refresh after clear cache): https://share.firefox.dev/4rLozR9

And here the same with the original project (refresh after clear cache): https://share.firefox.dev/4m0RHCV

I have pass both analyse to Claude Opus 4.6 and here his analysis:

"""
1. The JS bundle takes 2.6x longer to load (64.6ms vs 25ms)
The fork's index-cc64d09d.js takes nearly 3 times longer to download and parse than the original's. This is the first source of slowdown — the fork ships more JS code, likely the modules needed to handle tools-filter.json, external-tools.json, tools-settings.json, and the markdown rendering for home.custom.md.

2. The fork makes 4 additional network requests post-load
This is the biggest issue. After the initial page load, the fork sequentially fetches:

• tools-filter.json (14.5ms, at t+931ms)
• external-tools.json (6ms, at t+955ms)
• tools-settings.json (10.6ms, at t+1028ms)
• home.custom.md (79.6ms, at t+1975ms)

These files are loaded as a waterfall (each starts after the previous one), not in parallel. The original has none of these files — all content is already baked into the initial bundle or HTML.

3. home.custom.md is the last link in the chain → LCP at 2051ms
The fork's Largest Contentful Paint sits at 2051ms because the main page content depends on fetching home.custom.md, which doesn't even start until t+1975ms and takes 80ms. This markdown file triggers the final large repaint. Without it, the LCP would be much lower.

4. 2.7x more reflows (48 vs 18)
Each JSON fetch that mutates the DOM triggers additional reflows. The fork has 48 reflows vs 18, and total style recalculation time is 3x higher (140.9ms vs 45.4ms). This indicates the fork inserts content dynamically multiple times, forcing the browser to recalculate layout after each insertion.

5. Favicon takes 3x longer (909ms vs 305ms)
The icons (apple-touch-icon.png and favicon-16x16.png) are blocked for 909ms on the fork vs 305ms on the original. This is likely a server-side issue on the fork (slower response time) or an HTTP connection issue (no keep-alive, no HTTP/2).

Optimization recommendations:

• Preload tools-filter.json, external-tools.json, tools-settings.json, and home.custom.md in parallel (via Promise.all or <link rel="preload">), not as a sequential waterfall
• Ideally, inline this data into the initial HTML or JS bundle to eliminate the network round-trips entirely
• Investigate why the favicon takes 909ms (server issue?)
• Reduce reflows by batching DOM updates instead of mutating the DOM after each individual fetch
  """
  By Claude Opus 4.6

Here chart generate by Claude Opus 4.6

Note: oldittools.local is the original projet and tools.local is this actual fork. Both domain are in my host file and run on my computer in docker container behind traefik reverse proxy (also is a container). That mean that both container run in the same condition. The image take always the same time (more than 700ms) to render.