Improving FCP affects TBT

[althaf101]

We operate a web application that runs within a native app's web view. Previously, the application used to load certain dynamic JavaScript chunks before the First Contentful Paint (FCP), thereby delaying the FCP value. To optimize performance, we transitioned to statically loading these chunks via HTML and serving them directly from the HTTP Cache (We've implemented internal mechanisms to ensure critical code remains in the cache). Surprisingly, this optimization led to a degradation in Total Blocking Time (TBT), despite successfully improving the FCP value

Here is an illustration of the trace that we gathered for before and after

What we could understand from this is that the overall blocking tasks remain consistent between the before and after versions. However, the distribution of these blocking tasks concerning the First Contentful Paint (FCP) point differs. In the after version, a greater portion of the blocking tasks occurs after the FCP point. Consequently, this shift has led to a higher Total Blocking Time (TBT) value in the after version, as TBT is measured from the FCP mark. Despite significantly enhancing the user experience, this change has resulted in a lower or nearly unchanged Lighthouse (LH) score for the after version.

So I believe, in addition to TBT, we should also have some way to indicate the Overall Blocking Time. Measuring the blocking time from the FCP mark alone might not tell the real story. A decrease in the blocking time prior to the FCP mark should reward the application here.

[althaf101]

@adamraine
Could you please take a look at this ? This issue is blocking us from going ahead with our optimizations for FCP.

[adamraine]

In your case, the FCP being earlier in the page load would make users more likely to interact with the page sooner while the main thread is blocked which can increase interaction latency.

Ultimately this is just a trade-off for you to decide which aspect of the user experience you want to optimize, interaction latency measured by TBT or perceived load time measured by FCP. You could also look into reducing the main thread blocking time in the new TBT window to optimize both.

[althaf101]

Sure, I understand that TBT translates to the interaction latency. But I was trying to understand why is LH not penalizing apps for any blocking task that happens before FCP. I believe any blocking task prior to FCP could directly affect rendering of the page and hence could result in delayed paint metrics. So, irrespective of whether it happens before or after FCP, a blocking task is to be caught and LH should consider that in the final score.

In cases like the above, such blocking tasks goes unnoticed and this results in a plethora of undesired cases like below

1. It gives people an escape hatch to get better LH score. People could easily mask blocking tasks that contributes to 30% of LH score, just by delaying FCP which only accounts for 10%. Any platform team who relies on LH to perf audit their apps will be at disadvantage here
2. Any optimization done on the blocking task prior to FCP is not rewarded.

I believe we should start considering all the blocking tasks in the final score given by LH, not just the ones that happens after FCP

[adamraine]

believe any blocking task prior to FCP could directly affect rendering of the page and hence could result in delayed paint metrics.

If a blocking task delays FCP that will be reflected in the FCP metric value. So Lighthouse does penalize pre-FCP blocking tasks if they actually affect render delay.

Any platform team who relies on LH to perf audit their apps will be at disadvantage here

At a disadvantage how? It's perfectly reasonable to optimize render time at the expense of interaction delay if it's important for your use case.

Any optimization done on the blocking task prior to FCP is not rewarded.

Again, optimizing blocking tasks which delay FCP should be rewarded with an improved FCP score. We just don't count them in the context of interaction delay (i.e. TBT) because users are unlikely to interact with the page before FCP.

[althaf101]

If a blocking task delays FCP that will be reflected in the FCP metric value. So Lighthouse does penalize pre-FCP blocking tasks if they actually affect render delay.

Having to rely on FCP to indirectly understand the presence of a blocking task could introduce a lot of ambiguity here. For example, i might not know for sure whether FCP was delayed because of a blocking task or because of some other reasons.
Also, for blocking tasks that happens post FCP, we are not indirectly relying on LCP to understand the impact. Technically speaking, any blocking task post FCP will delay LCP and what you stated is applicable here too. But still we are measuring blocking time directly here.

Again, optimizing blocking tasks which delay FCP should be rewarded with an improved FCP score. We just don't count them in the context of interaction delay (i.e. TBT) because users are unlikely to interact with the page before FCP.

It makes sense to not count blocking tasks before FCP in the context of interaction delay. But in that case, may be we should think about replacing TBT with a new metric that combines these two sets of blocking tasks, one post FCP (today's TBT) and one pre FCP. Ignoring the pre FCP blocking task simply does not make sense here.

[adamraine]

Having to rely on FCP to indirectly understand the presence of a blocking task could introduce a lot of ambiguity here. For example, i might not know for sure whether FCP was delayed because of a blocking task or because of some other reasons.

This sounds like you are trying to understand the most impactful contributions to each metric which is the purpose of performance diagnostic audits. For example, the "Avoid long main-thread tasks" diagnostic audit will show you all of the long tasks that ran during the page load (before & after FCP)

Also, for blocking tasks that happens post FCP, we are not indirectly relying on LCP to understand the impact. Technically speaking, any blocking task post FCP will delay LCP and what you stated is applicable here too. But still we are measuring blocking time directly here.

Yes we are using LCP to understand the visual presentation delay caused by blocking tasks which is a separate aspect of the user experience than interaction delay covered by TBT.

It makes sense to not count blocking tasks before FCP in the context of interaction delay. But in that case, may be we should think about replacing TBT with a new metric that combines these two sets of blocking tasks, one post FCP (today's TBT) and one pre FCP. Ignoring the pre FCP blocking task simply does not make sense here.

The purpose of TBT is not to add more context to FCP & LCP it's to measure a different aspect of the user experience (i.e. interaction delay). As I said, we use performance diagnostic audits to identify contributing factors to each metric.