In general, you will not have a great real-time experience over websockets or other TCP-based transport. You should design games that must work in that environment to not require low-latency controls, because it's technically quite challenging to try to reduce the control latency over available channels.

I've heard of people trying to jam game control information into WebRTC transport, which can be UDP based, but I haven't seen anything successful out of such a project yet, and it would certainly require a lot of hard engineering at the browser interface layer to make work, if it works at all.

To solve the problem more fundamentally you need to account for the reality that time is not synchronized.

For this game you can treat the bottom-half synchronized to the blue player and the top half to the pink player.

You have to back calculate in time when the mallet would-have-collided with the puck, accounting for the lag, then fix the position and trajectory of the puck. I would add a little click noise and maybe some graphical flash to distract the player from the puck jumping in position.

How long does it take for the puck to travel from side A to side B when smashed?

If your ping is 80 milliseconds, and the puck travels in, say, 100 milliseconds, you're always going to be 80% out of date.

Generally, the local player will be displayed in a time frame “ahead” of the server, estimated such that the commands from the player will reach the server/other side just ahead of the server actually needing them. Separately, you will know which timestamp the received entities were calculated at; these will be at timestamps “behind” the server as they were sent out at that time and transmission takes time.

Regarding what @shannon barber said: The way “tennis” type games usually work, is that you have two time frames on the local client: “close to me” and “close to others.” When the puck is heading towards me, the puck, will be moved forward in time to my own time frame (which runs ahead of everyone else for obvious reasons); when the puck is heading away, it will be moved backwards in time towards the “others" or “server” time frame. The thinking is that, objects right near me, that I interact with, will be reactive to me, and hopefully nobody else will interact with them, so I don't get a lot of corrections because I extrapolate; once objects are further away, I'm less likely to interact with them, so interpolating based on received “true” data (that is older) is better, to avoid snapping when other people interact with the objects. At there.com we built a system that did this automatically for any physical object built in the system.

The end result is that you get a kind of “doppler” effect of physics – as objects move closer, they “speed up,” because they end up being displayed at closer and closer time frames, so they appear to simulate physics faster than real time; when objects move away, they seem to “slow down” because they get moved into further back time frames and thus appear to display the output of time stamps that advance slower than real time (until they reach the maximum delay, at which point they proceed normally again.)

So, for each simulated entity, you have functions something like:

class Entity {
  // this is the trail of states received from the server/network
  timestamp lastReceivedTimestamp;
  state lastReceivedState;
  timestamp previousReceivedTimestamp;
  state previousReceivedState;

  // this is how the object displays to the screen  
  void displayAtTimestamp(timestamp time);
  
  // you will likely end up needing these in implementation
  timestamp lastDisplayedTimestamp;
  state lastDisplayedState;
};

Now, when the game renders the object, it will provide a “timestamp" to “displayAtTimestamp” that is between previousReceived and lastReceived, for objects that are “far away,” and thus interpolated on the screen. For objects that are near, the “displayAtTimestamp” value will be made to be ahead of lastReceivedTimestamp, so the object will display itself extrapolated.