Which method you choose doesn't depend on packet loss or ordering; it depends on whether you want to always display a "correct" position (a position you know has happened in the past,) at the cost of additional latency, or if you want to display an "approximate" position (close to known correct possitions) with less latency.
Method 2 is fine, and will likely work well with websockets.
The main problem with TCP is the delivery jitter -- if there's any packet loss, there will be a significant delay before the TCP connection detects it and re-transmits, and then you'll suddenly get a whole bunch of packets all at once.

Which method you choose doesn't depend on packet loss or ordering; it depends on whether you want to always display a "correct" position (a position you know has happened in the past,) at the cost of additional latency, or if you want to display an "approximate" position (close to known correct possitions) with less latency.Method 2 is fine, and will likely work well with websockets.The main problem with TCP is the delivery jitter -- if there's any packet loss, there will be a significant delay before the TCP connection detects it and re-transmits, and then you'll suddenly get a whole bunch of packets all at once.

Thanks I understand the drawback. But I need to get it working first. Now I am using method 2. Currently right after the time sync the player will move abruptly towards random positions which are far away from each other for about 2 seconds before it gets stable and renders at correct positions.
Suppose player receives input from the mouse, now even my mouse is not moving at the beginning the player still jumps for a while before it starts to interpolate. I am not sure if this is buggy or expected behavior of a networking environment.

I am not sure if this is buggy or expected behavior of a networking environment.

That sounds buggy, if you're using interpolation. It could happen with extrapolation, but generally shouldn't unless the actual player movement is jumpy.

Think about it: If you use the previously-rendered position, and the next-received position, and interpolate linearly between the two, there's no way that a "large movement" should happen, unless you receive a very large position delta from the server.

To debug these kinds of things, I'd recommend recording each position/time received from the server to some kind of log file, and then perhaps also recording each position/time you get out of the interpolation code. If you then study these positions, you may be able to see patterns where you're not getting the result you want.
Once you have these log files, the next step is building a timeline display tool, that lets you "scrub" over time to render a frame based on the data, with a "ghost" for the last-received server position, as well as the player at the last-calculated interpolated position.

Visualizing data over time is crucial to a well-functioning distributed system. For straightforward code, you may be able to do it all in your head, but once multiple computers are involved, that each run on their own, getting concrete things you can study in freeze frame (be it logs, or timeline displays) is highly valuable!

In addition to the above, a very simple graphical diagnostic would be to render a translucent circle onscreen at the positions of both states, and draw a line between them. If those circles aren't where you expect, the states aren't right. And if your player isn't somewhere along the line, your interpolation isn't right.