I’m getting 60+ second reload times after refreshing the browser (no rebuild). Anyone know if this is normal? It’s becoming a pretty poor development experience.
I’m on meteor v1.10.2 using React on the front end.
I’ve tried profiling using the chrome performance tab which says 99% of the time is spent parsing HTML but I don’t really know how to use it.
Any help/guidance would be much appreciated!
Hi @lucaciraolo, is this happening in Windows or in Mac/Linux? How big is your code?. In Linux and Mac its definitely not normal, my code is very big and it takes 1s to reload but in windows it does take more time for me.
This is definitely no Meteor issue. We have an application with well over 10K files (plus dependencies) and we’re looking at 1-2 seconds reload.
That 99% time spent parsing HTML looks suspicious - Chrome may in fact be parsing a huge JS bundle in the head (or multiple very large scripts, when in dev mode), as explained here. It might be that some dependency is inadvertently leaking something big in the client.
Analyse the client bundle using bundle-visualizer.
This could be an indicator of an imperformant algorithm or mem-leak (depending on what the 99% refer to).
A good way to “find” the source is 1. using a static linter like eslint in combination with eslint-plugin-security and if this wont solve the issue 2. remove all import statements from your client and adding them back again one-by-one and see when the performance crash hits.
Thank you all for taking the time to help, I really appreciate it. I went the route of removing all components and slowly reintroducing them one by one.
I discovered that it’s material-ui icons that are causing the issue. I am using destructured import syntax because I thought tree shaking was supported in meteor but I guess not.
// bad as it loads all icons -> slow reload
import { Add } from '@material-ui/icons';
// good -> fast reload
import { Add } from '@material-ui/icons/Add';
I can’t believe I’ve been dealing with 60+ second reloads for a month now all because of this!
Its best to always deeplink in packages. Most npm modules have no treeshaking anyways unfortunately.
I think this issue could have been spotted using the bundle-visualizer and checking the bundle size at chrome dev tools.
For the icons, a shameless plug, I’ve forked react-icons to resolve this tree-shaking issue. It has material-ui icons and many other icon sets, check it out.
It has the following icons
| Icon Library | License | Version |
|---|---|---|
| Font Awesome | CC BY 4.0 License | 5.12.1 |
| Ionicons | MIT | 4.5.6 |
| Material Design icons | Apache License Version 2.0 | 3.0.1 |
| Material Design Community icons | SIL | 52442e9e6ea4424c41fb6489911c6f87fe83a7a8 |
| Typicons | CC BY-SA 3.0 | 2.0.9 |
| Github Octicons icons | MIT | 8.5.0 |
| Feather | MIT | 4.21.0 |
| Game Icons | CC BY 3.0 | a53463d41d4f055fa71097ae74da4c508c9bb09d |
| Weather Icons | SIL OFL 1.1 | 2.0.10 |
| Devicons | MIT | 1.8.0 |
| Ant Design Icons | MIT | 4.0.0 |
| Bootstrap Icons | MIT | 1.0.0-alpha3 |
| Remix Icon | Apache License Version 2.0 | 2.3.0 |
| Flat Color Icons | MIT | 1.0.2 |
| Grommet-Icons | Apache License Version 2.0 | 4.4.0 |
| css.gg | MIT | 2.0.0 |
| IcoMoon Free | CC BY 4.0 License | 1.0.0 |
| BoxIcons | CC BY 4.0 License | 2.0.5 |
| VS Code Icons | CC BY 4.0 | 0.0.1 |
| flag-icon-css | MIT License | 3.5.0 |
| Logos | CC0 1.0 Universal | 2018.01 |
| Simple Icons | CC0 1.0 Universal | 1.17.1-998-gd4b07ad4 |
| Heroicons | MIT | v0.3.7 |
| Twemoji | MIT | v13.01 |
Hello
I fully agree with you, there is NTFS issue, file system is very slow for small files. I have a good experience with big projects in Meteor only with Windows based on intel Xeon platinum and NVMe storage, in others cases MacOS and Linux is most recommended.