Improve Core Web Vitals Measurements (esp. Mobile)

[ChristopherChudzicki]

Google Search Console shows some warning regarding core web vitals on Mobile.

• [ ] Explain what the warnings mean
• [ ] What can we do to improve these metrics?

[ChristopherChudzicki]

Google Search Console issues some warnings for us about core web vitals:

• stable LCP (Largest Contentful Paint)
• stable FID (First Input Delay) an attempt to measure responsiveness to interactions
• stable CLS (Cumulative Layout Shift)
• Pending: INP (Interaction to Next Paint), which will replace FID in March 2024.
  • INP seems to be a much more meaningful measure of responsiveness than FID: FID only measures the first interaction, and does not include the time an even handler takes to run. INP is aggregated over all interactions, and measures from event until next paint, which can include event handlers.

Web vitals reported in Google Search Console are based on CrUX (Chrome UX) data, which is collected only from Chrome users who have opted in. Some web vitals can be measured "in the lab" with Lighthouse, but there are notable differences: e.g., Lighthouse's doesn't measure FID or INP (it does not "interact") and real users often start with cached data, so their initial load may be faster.

In general, at least for the three stable vitals, the vast majority of OCW course pages on both mobile and Desktop rate "Good". (none are "Poor"; a few hundred out of ~15K "Need Improvement").

From the discussion below, I am excluding old ans7870 pages.

Mobile Issues

Loading: Some mobile pages have high LCP, i.e., are slow to load., I don't see any clear difference between these and other pages, but

• 1212 (unstarted)

• 1201

  should help significantly, I believe.

Responsiveness: Some mobile pages have fairly high INP values, the new interaction responsiveness metric. In particular, Google has flagged:

1. http://ocw.mit.edu/search
2. Several other pages, many of which don't have sufficient users for Google to report actual INP values. Some do, though. They seem to contain videos.

Determining exactly what interaction is slow is not particularly easy. The web vitals chrome extension can help for some content, but does it cannot report about interactions that occur within an Iframe. (CrUX data does include iframe interactions, since those data are captured at the browser level, not via JS APIs.) For (2) I am suspicious that the Youtube player is the cause, because measuring the player directly on Youtube (which does not have an iframe) is a little slow.

Desktop Issue: Cumulative Layout Shift

The only issue Google noted for desktop users is pages with poor CLS, i.e., the content shifts a bunch during rendering. Based on the URL groups shown in Search Console, I believe there are two cases:

• Videos Ever since we switched to loading videos asynchronously, we've had some layout shift on videos. We should be able to. stop this with some styles on the placeholder divs.
• Course Lists: E.g., https://ocw.mit.edu/course-lists/scholar-courses/. The course list pages are rendered via a React component, which has no placeholder, hence the shift.

Recommendations

• 1212

• Possibly #1213
• We may also want to review whether all our GTM tags are actually necessary. Lighthouse indicates GTM is loading a lot of JS.

I have no recommendation for the pending INP issue, though tackling it for /search seems more straightforward than the other pages. I am interested to see if more pages get flagged.

[ibrahimjaved12]

The only issue Google noted for desktop users is pages with poor CLS, i.e., the content shifts a bunch during rendering. Based on the URL groups shown in Search Console, I believe there are two cases: Videos Ever since we switched to loading videos asynchronously, we've had some layout shift on videos. We should be able to. stop this with some styles on the placeholder divs. Course Lists: E.g., https://ocw.mit.edu/course-lists/scholar-courses/. The course list pages are rendered via a React component, which has no placeholder, hence the shift.

@ChristopherChudzicki Do you think this might be another case for desktop users?

The course-info navbar on the right, initially it is closed for a split-second, then it opens up by itself, shifting all the contents of the center div. This happens in a much shorter time as compared to the video player stuff.

Even after #1213 is fixed, the issue might still exist to a small extent. Because the dimensions of the video player are also different when the course-info navbar is closed/opened. So it will still go through a layout shift, although much smaller.