core-web-vitalscumulative-layout-shiftinteraction-to-next-paint

How to prevent browser built-in functions confirm/alert/prompt brings up high CLS and INP when updating screen after the function returns?


If you run confirm/alert/prompt functions and then update the screen after the function returns, the INP and CLS score will be very bad.

For instance, say I create a form to ask my students to enter their name, then I display some content after the input. After the user clicks "OK" to enter his/her name, the CLS and INS penalty score will boost.

$('button').click(()=>{
  var name =  prompt('enter your name:');
  $('#screen1').html(`${name} Hello!<p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p><p>
something ...
</p>`);
})
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div id="screen1">



</div>
<button>
Enter Your Name
</button>

I think this is a Web vitals bug. But is there anything I can prevent this for damaging my web vitals score?


Solution

  • For INP, this is something we're looking to fix before INP becomes a full Core Web Vitals next year: https://bugs.chromium.org/p/chromium/issues/detail?id=1435448

    Technically the main thread is blocked while the confirm/alert/prompt is showing, which INP seeks to address, and the event handler is still running, hence why it currently flags. In general these prompts are discouraged for this reason. On the other hand though, a paint HAS happened and feedback HAS been given (which is what INP aims to measure) hence why we want to handle this, even if it's still discouraged.

    For CLS, I am unable to see any shifts, even when running this outside of an iframe: https://www.tunetheweb.com/experiments/prompt/ Can you confirm you're definitely seeing CLS with this?