Hi,
Thank you for the NodesIconTweak add-on. I'm running into a serious performance problem in the admin panel and I think the root cause is on the JavaScript side.
**Symptom**
When I open a node (forum) for editing in the AdminCP, the corresponding browser tab pegs one CPU core at 100% for roughly 3–4 minutes before the page becomes responsive. This happens consistently, on every edit. The Firefox process responsible is the "Isolated Web Content" worker for that tab.
**Setup**
- XenForo 2.x (local dev instance: `localhost.local`)
- NodesIconTweak: latest version
- "Use icons from server" is selected (icons loaded from `data/xfa/nodesicontweak/icons/`)
- Only 12 PNG icons in that folder, each ~33 KB, 128×128 px
- OS: Linux Mint, browser: Firefox
- Forum has ~2 million posts, but the server-side load is not the issue (see below)
**HAR analysis (recorded the full edit-page load)**
The network timeline tells a very clear story:
| Time | Event |
|---|---|
| 0.0 – 0.6 s | Server delivers everything: HTML, CSS, JS bundles, 12 PNG icons, FontAwesome `regular.svg` sprite (116 KB). Total ~2.4 MB. All server responses fast. |
| 0.6 – 239 s | **No network activity at all. Browser tab at 100% CPU the entire time.** |
| 239.2 – 239.7 s | Browser suddenly fires 63 individual SVG requests: 41× `/styles/fa/solid/*.svg`, 22× `/styles/fa/brands/*.svg` |
So the server is healthy and the database is not the bottleneck — the hang is entirely client-side, inside the FontAwesome iconpicker JavaScript.
**Suspected cause**
It looks like `fontawesome-iconpicker.min.js` (439 KB) is being initialized on the node edit page even when "Use icons from server" is the selected mode. The picker appears to build DOM nodes for the entire FontAwesome 5.15 icon set (~1,500 icons) during init, which is what blocks the main thread for 4 minutes. The flood of individual SVG requests at the end confirms that all icons are being instantiated, not just the ones actually needed.
**Expected behavior**
When "Use icons from server" is the active mode, the FontAwesome iconpicker shouldn't be initialized at all — or at least it should be lazy-initialized only when the user actually switches to FontAwesome mode.
**Workaround currently in use**
None that's practical from the UI. I just wait out the freeze.
Happy to share the full HAR file if that would help reproduce. Thanks for looking into it!
Best regards,
Carsten
Thank you for the NodesIconTweak add-on. I'm running into a serious performance problem in the admin panel and I think the root cause is on the JavaScript side.
**Symptom**
When I open a node (forum) for editing in the AdminCP, the corresponding browser tab pegs one CPU core at 100% for roughly 3–4 minutes before the page becomes responsive. This happens consistently, on every edit. The Firefox process responsible is the "Isolated Web Content" worker for that tab.
**Setup**
- XenForo 2.x (local dev instance: `localhost.local`)
- NodesIconTweak: latest version
- "Use icons from server" is selected (icons loaded from `data/xfa/nodesicontweak/icons/`)
- Only 12 PNG icons in that folder, each ~33 KB, 128×128 px
- OS: Linux Mint, browser: Firefox
- Forum has ~2 million posts, but the server-side load is not the issue (see below)
**HAR analysis (recorded the full edit-page load)**
The network timeline tells a very clear story:
| Time | Event |
|---|---|
| 0.0 – 0.6 s | Server delivers everything: HTML, CSS, JS bundles, 12 PNG icons, FontAwesome `regular.svg` sprite (116 KB). Total ~2.4 MB. All server responses fast. |
| 0.6 – 239 s | **No network activity at all. Browser tab at 100% CPU the entire time.** |
| 239.2 – 239.7 s | Browser suddenly fires 63 individual SVG requests: 41× `/styles/fa/solid/*.svg`, 22× `/styles/fa/brands/*.svg` |
So the server is healthy and the database is not the bottleneck — the hang is entirely client-side, inside the FontAwesome iconpicker JavaScript.
**Suspected cause**
It looks like `fontawesome-iconpicker.min.js` (439 KB) is being initialized on the node edit page even when "Use icons from server" is the selected mode. The picker appears to build DOM nodes for the entire FontAwesome 5.15 icon set (~1,500 icons) during init, which is what blocks the main thread for 4 minutes. The flood of individual SVG requests at the end confirms that all icons are being instantiated, not just the ones actually needed.
**Expected behavior**
When "Use icons from server" is the active mode, the FontAwesome iconpicker shouldn't be initialized at all — or at least it should be lazy-initialized only when the user actually switches to FontAwesome mode.
**Workaround currently in use**
None that's practical from the UI. I just wait out the freeze.
Happy to share the full HAR file if that would help reproduce. Thanks for looking into it!
Best regards,
Carsten
