One of my remote site gets that error alot due to network latency.

Any thing I can check or have checked?
When it is happening?
anything?

If Jimmy is right, you can do some of the following:
1) From the PC the user is using, ping back to the LSF server. Keep in mind that you'll need a larger buffer size to more closely simulate a typical TCP payload, since ping is using a small (I think 32-byte) ICMP payload by default
2) Check the network switch for dropped packets in all of the following that apply: LSF Server switch port, Database Server switch port, client location border router (if physically connected via anything other than direct LAN access), client PC (again, if physically connected via anything other than direct LAN back to the LSF server)

Now if NONE of that is it, start using tmmon to see if anything odd is happening to the program behind the scenes. You're looking for stuff like programs waiting, or tons of client threads from the same PIDs (aka WebSphere threads). If that's the case, then you'll have to look a bit deeper, since you could have some sort of a performance bottleneck.

Call me if you need me, and if I can help in anyway.

Kwane

This is what happens usually on my remote site(s).

The users on remote site would call me. For example, they would try to submit a jobs, approve a req etc and they would get an hourglass then the sso.js error.

When I check the jobschd or the req, they are submitted/completed/approved at the server side.

Seems to me that the server "respond" back to the user took too long/timeout due to lost packet or whatever.

To clarify my post in relation to Jimmy's findings, I concur. While I have seen other reasons for this, if there is a remote site involved, it is almost always a latency issue first, and some other issue second.
This plagued me so much so at a number of retail clients, I modified a custom written load test tool to isolate this very set of issues.

Kwane