title: Why does PageSpeed Insights keeps returning a high TTI (Time to Interactive) for a simple game?
body: <p>I submitted my app/game/PWA to <a href="https://developers.google.com/speed/pagespeed/insights/" rel="nofollow noreferrer">PageSpeed Insights</a> and it keeps giving me TTI values &gt; 7000ms and TBT values &gt; 2000ms, as it can be seen in the screenshot below (the overall score for a mobile experience is around 63):</p>
  <p><a href="https://i.stack.imgur.com/6nORq.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/6nORq.png" alt="PageSpeed Insights Results" /></a></p>
  <p>I read what those values mean over and over, but I just cannot make them lower!</p>
  <p>What is most annoying, is that when accessing the page in a real-life browser, I don't need to wait 7 seconds for the page to become interactive, even with a clear cache!!!</p>
  <p>The game can be accessed <a href="https://carlosrafaelgn.github.io/pixel/" rel="nofollow noreferrer">here</a> and its source is <a href="https://github.com/carlosrafaelgn/pixel" rel="nofollow noreferrer">here</a>.</p>
  <p>What comforts me is that Google's own game, <a href="https://doodlecricket.github.io/" rel="nofollow noreferrer">Doodle Cricket</a> also scores terribly. In fact, PageSpeed Insights gives it an overall score of &quot;?&quot;.</p>
  <p>Summing up: is there a way to tell PageSpeed Insights the page is actually a game with only a simple canvas in it and that <strong>it is indeed interactive</strong> as soon as the first frame is rendered on the canvas (not 7 seconds later)?</p>
  <h2>UPDATE: Partial Solution</h2>
  <p>Thanks to @Graham Ritchie's answer, I was able to detect the two slowest points, simulating a mid-tier mobile phone:</p>
  <ul>
  <li>Loading/Compiling WebAssembly files: there was not much I could do about this, and this alone consumes almost 1.5 seconds...</li>
  <li>Loading the main script file, script.min.js: I split the file into two, since almost two thirds of this file are just string constants, and I started loading them asynchronously, both using <code>async</code> to load the main script and delay loading the other string constants, which has saved more than 1.2 seconds from the load time.</li>
  </ul>
  <p>The improvements have also saved some time on better mobile devices/desktop devices.</p>
  <p>The commit diff is <a href="https://github.com/carlosrafaelgn/pixel/commit/5d5e8478adbb8612a722d0accb6f3ba3b28b02b6" rel="nofollow noreferrer">here</a>.</p>
  <h2>UPDATE 2: Improving the Tooling</h2>
  <p>For anyone who gets here from Google, two extra tips that I forgot to mention before...</p>
  <ul>
  <li>Use the CLI Lighthouse tool rather than the website (both for localhost and for internet websites): <code>npm install -g lighthouse</code>, then call <code>lighthouse --view http....</code> (or use any other arguments as necessary).</li>
  <li>If running on a notebook, make sure it is not running on the battery, but actually connected to a power source </li>
  </ul>