# Performance hit from reflow and coordsAtPos
**URL:** https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294
**Category:** Uncategorized
**Created:** [October 25, 2019, 5:33am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294 "2019-10-25T05:33:59Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@louisstow](https://discuss.prosemirror.net/u/louisstow)
#### Post date: [October 25, 2019, 5:33am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/1 "2019-10-25T05:33:59Z")
I’m doing some performance testing and analysis with a large amount of nodes (~1000) and the biggest hit to performance I can see is Reflows or Layout thrashing. It seems to be due to the use of getClientRects().
Here is what Chrome reports:
It doesn’t have much information about why Layout is taking so long or what is causing it.
Here is what Firefox reports:
There’s more information here and it seems to suggest a reflow is triggered by the use of getClientRects.
This might need some sort of caching to not cause a reflow on every key press. Will look into this more but wanted to start a thread.
---
### Author:  [@marijn](https://discuss.prosemirror.net/u/marijn)
#### Post date: [October 25, 2019, 6:20am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/2 "2019-10-25T06:20:41Z")
You can’t cache layouts across content changes (since those changes change the layout). Who is calling `coordsAtPos` and why in this scenario?
---
### Author:  [@louisstow](https://discuss.prosemirror.net/u/louisstow)
#### Post date: [October 25, 2019, 7:59am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/3 "2019-10-25T07:59:54Z")
It was happening internally where `state.scrollToSelection > prev.scrollToSelection` in `updateStateInner` which sets a local variable `scroll` to equal “to selection” . This would then trigger this line to run:
`scrollRectIntoView(this, this.coordsAtPos(state.selection.head), startDOM);`
I’m not sure why this is being executed on every keypress, but even if I remove it I’m seeing reflows so maybe this is inevitable if content changes. In which case there’s not much that can be done to avoid it other than making the reflow faster.
---
### Author:  [@marijn](https://discuss.prosemirror.net/u/marijn)
#### Post date: [October 25, 2019, 8:31am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/4 "2019-10-25T08:31:14Z")
> [@louisstow](#):
>
> I’m not sure why this is being executed on every keypress
To scroll the cursor into view.
> [@louisstow](#):
>
> maybe this is inevitable if content changes
Yes, if the DOM changes the browser has to compute a new layout. That is indeed inevitable.
---
### Author:  [@louisstow](https://discuss.prosemirror.net/u/louisstow)
#### Post date: [October 25, 2019, 9:49am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/5 "2019-10-25T09:49:42Z")
> [@marijn](#):
>
> To scroll the cursor into view.
Even if the cursor is already in view? I might look into this part further and report back.
But ultimately you are right, computing layout is going to be necessary when the DOM changes. There might be things I can do on my end to make reflows cheaper however.
---
### Author:  [@marijn](https://discuss.prosemirror.net/u/marijn)
#### Post date: [October 25, 2019, 10:56am UTC](https://discuss.prosemirror.net/t/performance-hit-from-reflow-and-coordsatpos/2294/6 "2019-10-25T10:56:02Z")
> [@louisstow](#):
>
> Even if the cursor is already in view?
You don’t know that it is until you find out where it is.