Improving Tiptap's Performance for Anthropic's Claude Interface
As developers ourselves, we understand the challenges of integrating rich text editors into complex applications. When we saw the sluggish performance in Claude's interface, we knew we had to investigate.
Our senior engineer, Nicholas (HN username: nickthesick), dug into the implementation using Chrome Dev Tools. Here's what he found:
1. For every keystroke in the editor, there were two renders of the PromptInput component.
2. There a couple of extensions with the same name as reported in the Dev tools console (this can be resolved by making extension have a name property)
3. On every update of the editor, the editor is converted from HTML into markdown even though the user has not submitted their prompt yet.
Here's how to address them:
- With the latest release of Tiptap 2.5, you can now get much more performance out of your editor, if integrated correctly, there should only ever need to be the initial render of the editor & no re-renders on keystrokes. See our guide here for more information and an example: https://tiptap.dev/docs/guides/performance#react-tiptap-editor-integration
- Consider converting the editor content to markdown only on submission, right now it seems like it is causing an extra re-render by having to setState with the new markdown. If this is not possible, consider using a ref since this should be outside of react’s rendering cycle.
- Prior to Tiptap 2.5, a render of the component that called useEditor would have to completely re-initialize the editor, now it can reuse the editor instance which should make it less sensitive to re-renders but it is still recommended to reduce the amount of re-renders as possible to ensure a smooth typing experience
We're sharing this not to criticize, but to help. We're users and fans of Claude ourselves, and we want to see it perform at its best. We're always happy to assist fellow developers in optimizing Tiptap integrations.
We'd love to hear your thoughts on these findings. Have you encountered similar issues? Do you have other optimization strategies to share? Let's discuss how we can improve the developer experience for rich text editing in AI interfaces.
16 comments
[ 3.4 ms ] story [ 58.7 ms ] threadYou should try first and understand instead of downvoting. There's no shaming about it. I raised it because: It even avoids to mention them, which causes a lot of trouble in our implementations first and lead us to just implement most in prosemirror
1. We mention ProseMirror in the first sentence of the editor docs "Tiptap is a headless wrapper around ProseMirror - a toolkit for building rich text WYSIWYG editors [...]" at: https://tiptap.dev/docs/editor/getting-started/overview
2. We have a whole page on our docs about ProseMirror: https://tiptap.dev/docs/editor/core-concepts/prosemirror
3. We explain how to access the ProseMirror API in our documentation: https://tiptap.dev/docs/editor/extensions/custom-extensions/...
4. We have a section in the docs explaining the ProseMirror schema: https://tiptap.dev/docs/editor/core-concepts/schema#get-the-...
5. We mention ProseMirror in the first paragraph of the readme.md of the GH repo: https://github.com/ueberdosis/tiptap
6. We mention ProseMirror on the editor landing page "Powered by ProseMirror [...]" at: https://tiptap.dev/product/editor
Super curious to hear about your use case and what you need to know/develop in ProseMirror that we should mention in our docs :-)