Well, that's perfectly expected behaviour, imposed (among others) by the speed of light. Packets sent across the internet just take a while to arrive:
$ ping stackoverflow.com
PING stackoverflow.com (198.252.206.16) 56(84) bytes of data.
64 bytes from stackoverflow.com (198.252.206.16): icmp_req=1 ttl=53 time=85.1 ms
That tells me the RTT (round trip time) from my machine to stackoverflow.com is 85 milliseconds, which is fine for a website, but is enough to result in noticeable lag in a real-time game.
That's the bad news. The worse news is that this is a very hard problem to solve.
Professional real-time multiplayer games use several tricks to make the lag less noticeable. For instance, they keep track of the latency for every client, and try to "predict" where the player will be at the current point in time, even if those packets haven't arrived yet. But of course, if the packets arrive and the prediction turns out to be wrong, this would result in the player suddenly "jumping" to the right place. To work around that, they apply some smoothing between the predicted and last known location. If it's done well, this gives the illusion of real-time movement.
The other problem is that you cannot do your game logic solely on the client, because every client has a slightly different view of the world. It's OK to have the client do predictions, but the server should have the final say in whether the paddle hit the ball.