Long notes getting slow? Keep one long note fast as plain text

Short answer

A long note often gets slow because the editor draws the whole document on the page. Every line you add is more work on every keystroke.
The usual advice is to split the note into many pages. You don't have to, if the editor draws only the lines you can see.
Keep the note as one plain text file, such as log.md, in your own private GitHub repository. Open it in a browser editor that draws only the visible lines.
The whole file is still loaded when you open it. Only the drawing is limited, so a very large file can take a moment to open, but typing stays quick.

The problem

A work log that gets a few lines every day grows fast. The person who wrote this guide keeps one that is now about 26,000 lines, close to 1 MB.

In online documents, notes and wikis, a note this long became heavy. Typing lagged behind the keys. Splitting the log into pages would fix the speed, but then it is no longer one place to scroll through and search.

Why long notes get slow

Many online editors turn every line or block of a note into its own part of the web page. A short note has a few dozen parts. A long note has thousands, and the browser has to keep all of them up to date.

Each keystroke changes the note, and the editor then updates the page. When the page holds the whole note, that work grows with the length of the note, not with what you can see. This is why the common answer is "split it up".

Keep one long note fast

An editor can instead draw only the part of the note that is on the screen, plus a little around it. The note can grow, but the work for each keystroke stays about the same.

CodeMirror, an open source code and text editor for the web, works this way. Its official guide says it this way:

“To keep the editor responsive and resource use low, it will, when updating, detect which part of the content is currently visible (not scrolled out of view), and only render that plus a margin around it.”

That is from the “Viewport” section of the CodeMirror System Guide.

Two things to know:

It limits what is drawn, not what is loaded. The whole file is still read when you open it.
Plain text helps too. There are no blocks or embedded objects to lay out, only lines.

Set it up

On github.com, create a new repository. Choose Private, and check Add a README file so it is not empty.
Add one file for the long note, for example log.md. Keep adding to the same file.
Open the file in a browser editor that works with your GitHub repository and draws only the visible lines. Each save to GitHub becomes a Git commit, so every version stays there.
To write the same note from your phone, see Keep phone notes as plain text in your own GitHub.

Doing this with PlainHub

PlainHub is an online editor for files in your own GitHub repositories. Its editor is built on CodeMirror 6, so it draws only the lines on the screen:

Open app.plainhub.dev, tap Sign in, and approve it on GitHub's page. Choose your repository and open log.md.
When you stop typing for a moment, it saves on its own. The status at the top changes to Saved to GitHub ✓, and each save is a commit.
One observation, on the author's own machine: the same work log, about 26,000 lines and close to 950 KB, opened in about a second, and typing at the end of it did not lag.
Files over 1 MB take a little longer to open, because the whole file is loaded in an extra step.

Try it without signing in

FAQ

Do I have to split my long note?
No. Split it when it helps you find things, not because the editor gets slow.

Is the whole file loaded?
Yes. The editor reads the whole file. Only the drawing is limited to what is on the screen.

Does it have to be Markdown?
No. Any text file works. Markdown (.md) is a good choice because GitHub shows it formatted.

Sources

Checked: 2026-11-01