You're going to have to put some instrumentation in to find out the answer to these questions.
If you implement it incorrectly, A* becomes the same as Dijkstra's algorithm. This still always finds the shortest path, but in some cases takes a lot longer.
You need to produce some test-cases where A* should be considering only a small number of nodes, to check that it really is only considering the nodes it needs to (not going to the opposite side of the map, looking for a shorter route, because there can't be one (assuming no teleporters, time machines etc, in the map))
You need to "notionally" do network access to get these data for images. But the images might come from the browser's cache if they're already available. You can encourage or enforce caching through a combination of web server headers and a cache-manifest file. Or you can just preload your images when your game starts so they're already available.
Once you have an Image object in memory, and you're holding a reference to it, it's not going to go away and you can use it without a problem. But when a player comes back to play the game again (in the same browser session or a different one), the assets need to come either from the server or the browser cache.
Image elements don't work on that level. You can't ask the Image object for its binary data. You can in principle extract the pixel data from an image, which might be an idea for loading maps or other assets.
If you want to do file IO for arbitrary (non-image) files, use XMLHttpRequest.
You should probably do the simplest thing which can possibly work and work on performance later.
Use a single socket. In practice it is generally easier to work with fewer sockets (i.e. just 1) rather than lots. You can easily multiplex many clients on a single socket by just processing packets as they arrive.
However, you should still consider using TCP as it solves a lot of problems for you and might be ok, depending on what kind of game you are making.