As a point of contrast, I maintain a CI system at work, with a plain-old-HTML (almost javascript-free) log browser. Including ANSI syntax highlighting (server-r

As a point of contrast, I maintain a CI system at work, with a plain-old-HTML (almost javascript-free) log browser. Including ANSI syntax highlighting (server-rendered), timestamp tooltips, real-time updating, etc. Chrome has no problems loading >140k lines of logs (~10mb, biggest job I could find) and scrolling/searching/selecting/copying/etc. Obviously not as snappy as smaller logs, and also not as snappy as downloading the log file to browse in IntelliJ, but it works OK-ish. It's a lot higher than the ~20k line soft limit they described in the post! The biggest difference I could find is that Github Action's log browser generates 6 HTML elements with ~673 characters of HTML overhead per log line, whereas our own log browser generates 1 HTML element with ~45 characters of HTML element per log line (basically a single div with a timestamp attribute for a non-colored line). In that light I guess it's not surprising that browsers have more trouble with Github Actions logs given how much more work they are making the browser do to render each line of logs! The minimal-HTML nature of our log browser was an intentional design goal. It's interesting what kind of limits you hit: you cannot use opacity (too slow), no rounded corners (too slow), one-div-per-line is faster than using spans and line wrapping (no idea why), no per-line JS logic (attach your event handlers to the parent container and wait for propagation). Kind of restrictive, but it's certainly nice not to have to implement an entire virtualized scroll window (which I have done before, and would rather not do again if possible!)