Bigger TTFB for Discover trafic then from other sources.

[Szczepan Bielecki (Pimko)]

Hello, 
 
A lot of traffic on the Web is from Google Discover Feed, especially from Google App with referer: android-app://com.google.android.googlequicksearchbox/ . 
 
I see that traffic has a bigger TTFB around ~90 ms for P75, than from other sources. 
 
I start investigation: 

Traffic from the Google App is open in Custom Tabs and it’s counts to CrUX. 

Custom Tabs could be traced from Android device. 

Recorded tracing for open news from Google Discover and checked navigation related traces

On the record is some delay. I guess, that tasks are related to warmup Custom Tabs. 
 

There is something like UNO https://calendar.perfplanet.com/2024/uno/ . For that traffic UNO for P75 is ~90 ms from users. We start logging missing gaps for calculating TTFB with this gaps. 

 
The gap between startTime and redirectStart (this could be workerStart or fetchStart it depends) for P75 is ~ 85 ms. It’s almost the total value of UNO. 

I think that the “warmup” phase should not be included in the value of TTFB. It’s not related to the site. We can’t improve this. It’s browser delay. I guess that navigation could start after this phase. 
 
Sites where a lot of traffic is from Google Discover have a worse TTFB than direct traffic. 

[Barry Pollard]

Hi,

Thanks for the detailed analysis here. I'll see if we can forward it on to the relevant team. I know that they are very keen to reduce these sorts of delays (see this recent post as an example of delays like this which they worked on reducing).

I think that the “warmup” phase should not be included in the value of TTFB. It’s not related to the site. We can’t improve this. It’s browser delay. I guess that navigation could start after this phase. 

The same thing can be said of redirects which are often (at least somewhat) out of control of the site. However, one of the key aims of the Web Vitals initiative is that they are user-centric metrics and aim to measure what the user experienced. They don't care who's "fault" it is, or who's able to fix it—they just measure the time the user experienced, which in this case is from when they clicked until they saw the content. This may seem unfair to site owners, but also works both ways—when browsers improve things internally (and we've seen a lot of this from Chrome in the last year!), then site metrics improve even if the site has not made any change.

This is also why CrUX measures Core Web Vitals at the 75th percentile. We recognise that users and conditions vary and we want to measure what the vast majority of users experienced, accepting that some users had worse experiences (btw, we do recommend sites look beyond 75th percentile as appropriate, but as a broad "measure" of the site the 75th percentile works well in our opinions). We also advise sites to ensure they have a reasonable buffer for changes in site traffic and sources, so if you are passing Core Web Vitals thresholds for 75.0001% of users and LCPius 2499 then that is not a great buffer and you're liable to flip in and out of traffic.

So while a ~85ms delay is not great, and we'll see what we can do to reduce that, I don't think this is an extreme a case to justify an exception to the above principles.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/b133934f-1988-44d2-a396-473f5dec00c5n%40googlegroups.com.

[Szczepan Bielecki]

Thanks for Your explanation !

 

I'll see if we can forward it on to the relevant team. I know that they are very keen to reduce these sorts of delays (see this recent post as an example of delays like this which they worked on reducing).

It's great to hear that.