I saw some misunderstandings about this cropping up in recent questions, so I thought it would help to cite the documentation here too: (emphasis added)
Indicates how much time your application spent waiting for the targeted FPS that Application.targetFrameRate specifies.
If the sample is a subsample of Gfx.WaitForPresentOnGfxThread, it represents the amount of time that your application spent waiting for the GPU. For example, this could be time that the GPU spent waiting for the next VSync, if that is configured in QualitySettings.vSyncCount, or if vSync is enforced on your target platform. However, samples with this marker are also emitted if the GPU hasn’t finished computing the frame.
To determine what is causing samples with this marker to use a lot of time, switch to the Timeline view in the CPU Profiler module. In this view, you can check what happened on the render thread and how much time passed between this sample ending in the current frame and the same sample ending in surrounding frames.
If the duration is larger than your application’s frame time should be (based on the targeted frame rate or vSync) your frames are taking too long to render or compute. If that’s the case, investigate the render thread and see how much time it spent on Gfx.PresentFrame over other work it did to prepare and issue commands to the GPU. If the render thread spent a large amount of time in Gfx.PresentFrame, your rendering work is GPU-bound. If the render thread’s time was spent preparing commands, your application is CPU-bound.
To find out what to focus on, if your application is GPU bound, profile the GPU work with the Unity Profiler or a platform profiler. For more information, see the User manual documentation on how to optimize graphics performance.
Note: The Editor doesn’t VSync on the GPU and instead uses WaitForTargetFPS to simulate the delay for VSync. Some platforms, in particular Android and iOS, enforce VSync or have a default frame rate cap of 30 or 60.
So: seeing high amounts of time spent in WaitForTargetFPS is not necessarily a problem.
If your overall framerate is still on-target, then this just means you have extra frame time headroom that the editor is burning, rather than simulating and drawing frames far faster than your display could ever keep up. It's a good sign that your CPU and GPU work finished so fast that you have this extra time to kill. In a build, this is time when your thread would usually be sleeping, saving power and heat.
High usage by the WaitForTargetFPS marker is only a problem if your overall framerate is dropping lower than your goal. In that case, follow the advice in the docs quoted above to identify which part of your code is taking up most of this marker time to figure out whether it's CPU or GPU work that's running behind.
In the screenshot here, the total frame time is still averaging about 10 ms, or 100 FPS, so this example is soundly in the "not a problem" category. That's why the other answer recommends just toggling off visualization of this spare time if seeing it in the graph is distracting.