Noticable lag in a simple OpenGL program with mouse input through GLFW

So yeah the usual approach to synchronising rendering to frame rate is with SwapInterval(1) and you weren't doing that, but that's not where the lag is coming from. In fact, typically with SwapInterval set to 0, you get less lag than with it set to 1, so I suspect it was actually set to 1 the whole time. So, I'm writing the rest of this supposing SwapInterval was set to 1.

You are seeing this lag for two independent reasons.

reason 0: your code is impatient.

Glossing over some details, the naïve method of rendering in OpenGL is with a loop like this:

while (!exitCondition()) {
    pollEvents();
    render();
    swap();
}

This loop is run once per frame. If render() is fast, most of the time is spent at swap(). swap() doesn't actually send out the new frame, though, until the moment it returns. New mouse and keyboard events may happen that entire time, but they will have no effect until next frame. This means the mouse and keyboard information is already one to two frames old by the time it reaches the screen. For better latency, you should not be polling events and rendering immediately after swap() returns. Wait for as many new events as possible, render, then send the frame just in time for it to be displayed. As little time as possible should be spent waiting for swap(). This can be achieved by adding a delay to the loop. Suppose tFrame is the amount of time between frames (1s/60 .= 16.67ms for a 60Hz screen) and tRender is an amount of time that is usually greater than the amount of time render() takes to run. The loop with the latency delay would look like this:

while(!exitCondition()) {
    sleep(tFrame - tRender);
    pollEvents();
    render();
    swap();
}

Patience is a virtue in computing too, it turns out.

reason 1: glfwSwapBuffers() does not behave like you would expect.

A newcomer would expect glfwSwapBuffers() to wait until the vsync, then send the newly-rendered frame to the screen and return, something like the swap() function I used in reason 0. What it actually does, effectively, is send the previously-rendered frame to the screen and return, leaving you with a whole frame of delay. In order to fix this, you have to obtain a separate means of synchronising your rendering, because OpenGL's mechanism isn't good enough. Such a mechanism is platform-specific. Wayland has such a mechanism, and it's called presentation-time. GLFW doesn't currently support this, but I was bothered so much by this synchronisation problem that I added it. Here's the result:

As you can see, it really is possible to synchronise rendering to the system cursor. It's just really hard.

Your updates are purely event driven. Try replacing glfwPollEvents with glfwWaitEvents. I would then reimplement glfwSwapInterval(1). You gain nothing by updating more frequently than the monitor refresh rate - just tearing and burning through cycles.