If you observe more javascript in recording than when comparing to manual execution with a tool like Fiddler running, perhaps examine those other javascript files with the developers to determine under what condition they might be fetched to the client side. It could even be something simple like browser-specific script with LoadRunner set to run generic browser emulation.
The javascript files are not actually going to execute on VuGen replay, but are only going to be downloaded as client-side resources (just as with an image file or style sheet file). The execution of the javascript while recording in VuGen should only capture if the client-side javascript makes server-side calls.
It sounds like you have commented out any javascript that does not get captured within Fiddler, and then saw response time similar to the response time observed by manually logging in. If that is the case, then you are likely on the right track. Beyond that, you can add individual transactions (or sub-transactions) for all calls to the server that occur during the logon process. That should give you a clear picture of where exactly the slowness resides.
Something like this:
lr_start_transaction("Login_00_Main");
lr_start_transaction("Login_00A_Post1");
some post
lr_end_transaction("Login_00A_Post1", LR_AUTO);
lr_start_transaction("Login_00B_Post2");
another post
lr_end_transaction("Login_00B_Post2, LR_AUTO");
lr_end_transaction("Login_00_Main, LR_AUTO");