Don't await on page load for sentiment analysis

[beaufortfrancois]

By not awaiting for the sentiment analysis pipeline to be fully loaded before displaying any content on page load, we improve the LCP score from 3.10s to 0.75s - a 75.81% improvement on a 470Mbps high-speed internet connection.

This should hopefully be a best practice in documentation like https://web.dev/articles/llm-sizes.

Before: After:

@maudnals Please review

[maudnals]

LGTM, thanks! Re: Documenting best practices: yes, we're planning on documenting a few tips for on-device perf. FWIW, we did mention a few pointers in our on-device I/O guidance, such as caching models and "Don't block the page on model download" (...yet it was not applied here).

[beaufortfrancois]

@devnook Shall we be able to merge ourselves or should we ask you to review this PR and merge?

[devnook]

You can merge yourself, but you need to have 1 approval review from a peer. E.g. Maud needs to click "approve" in her review to unblock it.

[beaufortfrancois]

@devnook Do I need to run some commands to sync this repo with chrome.dev content or is it going to be magically synced at some point?

[beaufortfrancois]

For future reference, here are the commands I ran to upload this PR to chrome.dev:

gh repo clone GoogleChromeLabs/web-ai-demos
cd web-ai-demos/product-reviews/
npm i
npm run build

Then I uploaded the dist folder to the appropriate bucket storage folder.

https://chrome.dev/web-ai-demos/product-reviews/ is now updated. @maudnals Did I miss anything?

[maudnals]

No, looks good. At the moment, the Gemini API part of the demo doesn't work (which is OK as the demo focuses on on-device AI) - not because of this PR, but because building the demo with an API key means having the API visible in the frontend via import.meta.env.VITE_GEMINI_GENAI_KEY. This design worked fine for a local demo but we don't want to deploy this as-is. In the future, we should think of moving the Gemini API functionality to a node server.

Thanks for this fix!