Improve performance of tabindex module#228
Improve performance of tabindex module#228hippotastic merged 7 commits intoexpressive-code:mainfrom delucis:chris/tabindex-perf
tabindex module#228Conversation
✅ Deploy Preview for expressive-code ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Thank you for this PR! If I remember correctly, one of the reasons why I used |
Good question. No, I didn’t think to test that — I will. We actually have similar logic for resizes for something in Starlight where I ended up with |
|
Did some testing, and it does look like with only the I also noticed that running tests updates the minified version which appears to be committed to the repo so I’ve included that update too. Is that correct? |
|
Hmm, hold on, just tested this in withastro/starlight#2155 and seeing the old behaviour again. I think I’ll need to investigate a bit further. EDIT: I may just have messed up my patch in that PR. Testing again now. |
|
Ah yeah, seems to be something to do with Netlify’s caching of the |
|
@hippotastic Do you need anything else from me here? I think this PR should be good to go! |
|
No, I also think it's fine! Thank you :) |
|
I've just released your fix as v0.35.4. Thanks again! |
This PR aims to improve performance of the script which applies/removes
tabindexattributes to code blocks depending on whether or not they are scrollable.While looking into some performance details on lower-powered devices, I realised that because this script reads element dimensions (
scrollWidthandclientWidth), it could cause forced style recalculation/layout work if running while this information is not yet fully resolved (for example during initial page load).This PR wraps the tab index update logic in a
requestIdleCallback(), to defer settingtabindexto a moment when the main thread is idle. In general this means that any required style/layout work the browser has planned will be complete before Expressive Code tries to measure anything.I also removed the initial call to
updateTabIndex()made at the same time as adding an element to the resize observer. In my testing,ResizeObserveralready fires its callback immediately for every newly observed element, so manually callingupdateTabIndex()was redundant.I tested this alongside another change in withastro/starlight#2155 which allowed the
DOMContentLoadedevent to fire quite a bit earlier on a throttled CPU.