Cross origin fonts significantly slow down rendering
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 18.3k
- Forks
- 2k
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 28
Description
Hi,
First of all, thank you for offering such a high quality rendering library! I have realized an issue that concerns Plotly loading cross origin fonts that significantly slows down rendering upon a visitor's first visit. The caching solves the problem which is why it may be hard to detect on often visited websites. Precisely, I am trying to use the following example: https://plotly.com/javascript/3d-surface-plots/
Loading from disk vs requesting from a web server
If one creates a minimal working example (just bare HTML and JavaScript) and loads the HTML directly from disk, the rendering is almost immediate. If however, one loads the same HTML via a web server, the time taken for the page to load is extremely slow, hinting towards cross origin requests. For reproducibility, one can create a web server from a directory fairly quickly using Python using python -m http.server 8000. Also, make sure that you load the minimal working example in a Private browser window, to ensure that the cache is not used, which will mask the problem.
Partial fix
To confirm that the issue is indeed due to Plotly's use of fonts, I was able to mitigate it by wrapping the plot command as follows. This workaround does not speed up the rendering of the Plotly plot, it only ensures that the rest of the page is not withheld from rendering due to this plot. Plotly figure shows up later.
requestIdleCallback(() => {
document.fonts.ready.then(() => {
Plotly.newPlot('plot3d', data, layout);
});
});
Without document.fonts.ready, the browser continues to show the loading icon. After adding it, the page load completes reasonably fast, but until we wrap with requestIdleCallback, the browser withholds the entire webpage from rendering due to just the Plotly plot. Note that Safari does not natively have requestIdleCallback and it must be defined manually.
Reproducibility
I suggest using the Private mode of your browser to reproduce this issue (since cache masks it). I personally found the issue more pronounced in Safari rather than Firefox. Also, as mentioned earlier, Safari does not natively have requestIdleCallback and it must be defined manually.
Ideal fix
Since there is no computational bottleneck in the rendering (as evidenced by the fact that loading from disk is fairly fast), there should be a convenient way to make Plotly fall back to system fonts (so far I have been unsuccessful in getting Plotly to use system fonts). Additionally, the document.fonts.ready + requestIdleCallback workaround is only partial. It lets the rest of the page to load, but ideally we still want everything (including the Plotly plot) to load fast. It is clearly possible, as evidenced by the fact that rendering happens immediately when loading from disk.
Any help is greatly appreciated. Thank you very much!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the 3D surface plot example at https://plotly.com/javascript/3d-surface-plots/ through python -m http.server 8000 in a private browser window, comparing disk loading with web-server loading. Start at the Plotly.newPlot entry point and investigate first-visit cross-origin font loading. Done means the plot and surrounding page render promptly without relying on the document.fonts.ready and requestIdleCallback workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100