第一个解决方案，也是最常见的解决方案之一，是引入悬停进入/退出延迟。我们需要确保菜单不会打开，也不会过早关闭。为此，我们引入了延迟，通常为 0.5 秒左右。这意味着我们为客户提供大约 0.5 秒的缓冲时间：
如果需要，穿过轨迹到达远程目标，或表明他们打算通过留在大型下拉类别链接上来探索导航，或者如果他们不小心离开了大型下拉菜单的边界，请纠正错误。
换句话说，只要客户停留在大型下拉覆盖范围内，我们就会继续显示它。一旦客户将鼠标光标移出子导航覆盖层至少 0.5 秒，我们就会隐藏覆盖层。
虽然它解决了页面意外闪烁的问题，但它会在用户离开超级下拉菜单超过 0.5 秒的情况下引入延迟。结果，它减慢了与整个站点上的大型下拉列表的每次交互。不幸的是，它很快就会变得非常引人注目，尤其是在导航使用很多的情况下。
一些实现添加了淡入/淡出过渡以使巨型下拉菜单的出现不那么突然，但实际上它导致进入/退出延迟增加到 0.8-0.9 秒，这也引入了更明显的落后。ADAC.de就是一个例子，它具有 100 毫秒的淡入延迟和 300 毫秒的淡出过渡。（不过，在大型下拉菜单的不同类别之间切换时，这种转换并不适用。） 显然，覆盖层保持可见的时间越长，我们对有意逃离覆盖层的人的惩罚就越严厉。实际上，这会成为一个问题，因为我们在用户操作和 UI 响应之间引入了一个表面上的超时。
