You aren’t real specific about exactly what you’re doing so about the best we can do here is to give you general advice about a bunch of relevant areas.
DOM Modifications
You don’t quite fill in all the details of what you’re trying to do, but here are a bunch of things to take into consideration when optimizing how your code works:
-
Reflows are already queued. The browser already attempts to minimize reflows so if you do four dom modifications in one sequential piece of Javascript, the browser will wait for that piece of Javascript to finish running and then do one reflow and one repaint.
-
Requesting certain properties can trigger an immediate reflow. There are exceptions to the above rule that you want to make sure you avoid. For example if you request certain DOM properties that require proper layout for the property value to be accurately reported and there is a pending layout from a prior modification, then the browser may relayout the document synchronously before returning the property you requested. These type of properties usually involve things like screen position and other properties that would obviously be affected by the layout of the document. There are many articles on this topic if you want to find further details. In many cases your code won’t be using these properties anyway, but if so, the usual workaround is to request all the needed properties first before making any changes to the DOM.
-
Batch up all your DOM changes at once. The worst thing to do is to make a DOM change, wait a few ms with a timer, make another DOM change, wait a few ms with a timer and so on because you will have DOM change, reflow, repaint, DOM change, reflow, repaint, etc… Instead, make sure you’re doing all pending DOM changes at once in one synchronous piece of Javascript. This will then allow the browser to queue the reflow and repaint and do it only once after you’ve made all your DOM changes. If you want to get even smarter about the batching, you will collapse modifications to the same element so that it is only processed once with the final value. So, if elementA was first given a new value of 3 and then later in the same batch was given a value of 4, when processing the batch of data, you want to skip the 3 and just process the 4.
-
DOM modifications can sometimes be optimized. You don’t give us any specifics on how you are modifying the DOM, but if you are modifying complex objects (like adding many table rows or changing lots of table cells), then it is sometimes better to create a set of DOM elements that are not currently inserted in the DOM, make all your modifications to them and then with one operation, insert them into the DOM. This is because modifying DOM elements that are currently inserted in the DOM forces the browser to figure out which other DOM elements are affected by this change so it can queue the appropriate reflows or repaints. But modifying off-screen DOM elements does not have to do any of that work until the one last step where one larger object is inserted into the DOM. There is no useful generic rules here because how you take advantage of this optimization depends entirely upon what DOM modifications you are doing. We could help you with this, but only when we could see both the HTML you have and exactly what changes you’re making to it.
Timing of Updates
Now, as for the timing of things, you mentioned up to 250 times per second. That’s kind of fast (4ms per operation) for a user viewable thing. If you do that, your browser is basically going to be constantly reflowing and repainting with only occasional pauses to process other user events. Since no user can actually see something happen at 4ms, 8ms and 12ms from now, there’s really no need to update status on screen that often.
So, if you really have changes coming in that fast or often, you may want to batch them by accumulating them into a local data structure and then just updating the screen every 100-500ms or so. You’d have to experiment with what the long interval you could use and not really notice any delay.
There are several implementation strategies for batching the updates. The simplest I can think of if your modifications are always streaming in constantly is to just put the modifications into a local array as they come in and then just have an interval timer set for your update interval that checks the array and if there’s anything in it, it process all the items in the array into a DOM update.
Getting Changes From Server
You don’t mention how the browser Javascript is getting the new data. There are generally two options, repeated Ajax requests or create a webSocket and the server can directly send you data at any time.
If your updates are regularly and shortly spaced, the webSocket connection is clearly the most efficient. It’s one constant connection and the server can just send each client new data whenever the server has new data to send.
If you’re going to be polling with Ajax, then I’d strongly suggest you lengthen out the polling interval. A very short polling interval will both really load your server and eat the battery on the client.
Battery
If this app is intended to run for long periods of time on a battery powered device, then getting a steady stream of data real-time (e.g. every few ms like you mentioned) from any server is going to eat battery because the radio (WiFi or Cellular) will be active nearly all the time and the CPU is going to be running a lot too.