I group performance metrics by the user experience they measure.
For loading performance, First Contentful Paint tells us when the first content appears. Largest Contentful Paint measures when the largest eligible content element in the viewport renders, making it a useful indicator of when the main content becomes visible. Speed Index measures how quickly the viewport fills with visible content, while Time to First Byte helps identify delays in receiving the initial server response.
For responsiveness, Total Blocking Time is a lab metric that quantifies blocking caused by long main-thread tasks. First Input Delay measured only the delay before the browser could begin processing the first user interaction. Interaction to Next Paint is more comprehensive because it assesses interaction latency throughout the page lifecycle.
For visual stability, Cumulative Layout Shift measures unexpected layout movement.
Historically, Lighthouse also reported First Meaningful Paint and First CPU Idle. Those metrics were deprecated, and TTI was removed from Lighthouse 10. I would recognize them when reading older reports, but focus on currently relevant measurements for optimization.
For current Core Web Vitals, the ‘good’ targets are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, assessed at the 75th percentile of real-user visits.
Google for Developers
For a real project, I would first identify the page's main user journey, examine LCP, INP, and CLS in field data, and use Lighthouse traces to investigate suspected loading or main-thread bottlenecks. I would then implement a targeted optimization and compare measurements under comparable conditions. I would report actual before-and-after results rather than assume an improvement

This is my answer

In order to do performance tuning we need to first know how to evaluate the performance. Here are metrics used in Chrome Lighthouse, can you explain t…