Online games do not work the way you describe. The server doesn't give the client one frame's worth of data every frame. That would be awful. Instead, every client has its own copy of the game state, and the rendering happens as if it were an offline game: every frame, the game state is updated locally. That means your inputs such as moving the mouse to control the view take effect immediately. Things that aren't under players' control (such as the movement of projectiles in flight) are also updated locally. Many games also have some kind of motion prediction for other players' characters - in the simplest case, just updating the state as if they kept going in the same direction.
These state updates are performed by the CPU on its scene-graph, and they result in some update to GPU state too. The frame is then rendered by the GPU, usually in parallel with the CPU starting work on the next frame's updates.
When an update arrives from the server, this also updates the state on the CPU. This update will include new projectiles, replacements for the predicted motions of other player characters, and replacements for the motions of the local player's character (e.g. if they bumped into another player or were hit by some unpredicted projectiles).
Resolving conflicts between the predicted state on the client and the new state from the server, and applying the lag to the server state before applying it, are important parts of the game's architecture that really determine how the game feels to play and what lag looks like. Applying the updates from the server is done within one frame update on the client, so if an update takes too long to apply, it'll cause some frames to be much slower, but the age of the update doesn't really affect that.
Client-server latency doesn't usually increase the frame time, because the client doesn't wait for a server round-trip each frame.