Is it worth spliting up a large JavaScript file into many smaller one?

I am currently working on a game where I need to define many functions for the game that is played on a single HTML page. Currently, I have implemented all functions on one JavaScript file however this file is getting very large and doesn't look as "neat" or as "easy to read".

I am thinking that maybe I should have a file each for a set of functions. This fixes the above problem but also means that there will be a lot more js files to load, although the overall code being referenced by the webpage is still similar.

Im not sure if the second approach is worth taking. What factors do I need to consider when making a decision and what are the consequences of both decisions?

Currently have all js code on one file.

A big issue to consider when having lots and lots of small script files is that, if your web server uses HTTP 1.1, there's a hard limit to how many files can be being transferred at once. If there are many files, it could take a long time for an app to fully load if the client's ping is bad.

(If your webserver uses HTTP/2, no such limit exists; lots of tiny files can work just fine, and can be used in combination with <script type="module">.)

A common approach is to write in many different source files for readability's sake, but to use a build system like Webpack to take all of those files and transform them into a single larger bundle (or few) for download by clients. Bundles will work well no matter the network protocol of your server. Also, having a build process (any build process) is helpful anyway for many other things, such as Babel to transpile down new syntax into old syntax and minification to reduce the number of bytes that need to be transferred.