Research: How to improve load time for Flutter Web App

[nelsonic]

At present the PageSpeed Insights for the https://dwylapp.fly.dev/ Flutter App
are quite poor for Performance: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwylapp.fly.dev%2F

Todo

• Research what we can do to improve this page load time.
• e.g. can we "fake" it with a static HTML landing page that then loads the App in the background and replaces the HTML page once the Flutter App has loaded? -> Feat: Loading Screen  #319 -> [PR] Adding splash screen #321
• Deploy the Flutter Web App to GitHub Pages: Feat: Deploy Flutter Web App to GitHub Pages  #322 -> [PR] Deploy to Github pages. #323

[SimonLab]

The answer might be a bit old, but maybe there are some ideas we can try from this:
https://stackoverflow.com/questions/64127202/flutter-web-website-takes-a-long-time-to-load-initially

[nelsonic]

Can we start by updating the Flutter SDK from:

app/pubspec.yaml

Lines 21 to 22 in b067343

	environment:
	sdk: '>=2.19.0 <3.0.0'

To the latest possible version of Flutter?
e.g: https://github.com/flutter/flutter/releases/tag/3.7.3 at the time of writing.
See: https://www.theregister.com/2023/01/25/flutter_3_7/

Is there a way to compile to WebAssembly https://docs.flutter.dev/deployment/web ?
Or is the App on Fly.io already Wasm?

[nelsonic]

I'm inclined to include the Flutter App in an <iframe> on dwyl.com as per:
https://docs.flutter.dev/development/platform-integration/web/faq#how-do-i-embed-a-flutter-web-app-in-a-web-page

That way when the person visits app.dwyl.com most of the (minified) JS for the page has already loaded in their browser. Obvs this doesn't solve the initial page load time problem. but it does improve the UX for people visiting the dwyl.com landing page and then subsequently opening the app ... ⏳

[nelsonic]

@SimonLab please have a look at: https://stackoverflow.com/a/71456514/1148249 🤞

[nelsonic]

My reading of https://dwylapp.fly.dev/main.dart.js

Is that is very far from "optimised" or minified ... 🐌

It's 2.2 MB when downloaded:

This is absurd. And is the most immediate "low hanging fruit" we can tackle to improve load time.

We need to go through: https://docs.flutter.dev/deployment/web
and make sure that the Flutter Web version of our App is as efficient as possible.

[LuchoTurtle]

Can we start by updating the Flutter SDK from:

app/pubspec.yaml

Lines 21 to 22 in b067343

	environment:
	sdk: '>=2.19.0 <3.0.0'

To the latest possible version of Flutter? e.g: [flutter/flutter@3.7.3 (release)]

The environment section in the pubspec.yaml file does not pertain to the Flutter SDK version but to Dart SDK, which is currently at 2.19.0 (check https://dart.dev/guides/whats-new#january-25-2023-219--30-alpha-releases).
There's a 3.0.0 release but it's still in alpha.

[LuchoTurtle]

I'm going to share another solution that is mentioned in flutter/flutter#76009 (comment), which was mentioned in https://stackoverflow.com/questions/64127202/flutter-web-website-takes-a-long-time-to-load-initially.

It basically involves adding a loading/splash screen while the app loads.

This should address the poor Performance metric on Lighthouse.

[LuchoTurtle]

Ran Lighthouse on the webapp linked after implementing a splash screen and Lighthouse seems to like it.

I can start working on adding a splash screen for the web 👍

[nelsonic]

@LuchoTurtle lets test adding Load/Splash screen to one of the deployed Demo apps to test it. I’m strongly against loading screens. They are a crutch for poor engineering. But I also understand the psychology of waiting and progress bars. I just think they show ineffective engineering. 💭

[nelsonic]

As noted above #315 (comment) the main.dart.js file is currently massive! ⏳

The flutter build command in ci.yml is currently:

app/.github/workflows/ci.yml

Lines 59 to 60 in 7f689cc

	- name: Create release build
	run: flutter build web

I suggest we attempt to follow the docs: https://docs.flutter.dev/development/platform-integration/web/renderers#examples

At at the very least add the --release flag to our build command, e.g:

flutter build web --release

Also considering changing the renderer to html to see if it makes a difference to accessibility score. 💭
So:

flutter build web --release --web-renderer html

Anyone have any objections to me making these changes? 🚧

[LuchoTurtle]

I don't. I thought flutter build web would produce a release build, even if the --release argument was present or not.

source: https://docs.flutter.dev/testing/build-modes#release

However, I feel like adding those flags won't make a difference.
When running flutter build web --help,
the following line appears:

    --release                                           Build a release version of your app (default mode).
    --web-renderer                                      The renderer implementation to use when building for the web.

          [auto] (default)                              Use the HTML renderer on mobile devices, and CanvasKit on desktop devices.
          [canvaskit]                                   Always use the CanvasKit renderer. This renderer uses WebGL and WebAssembly to render graphics.
          [html]                                        Always use the HTML renderer. This renderer uses a combination of HTML, CSS, SVG, 2D Canvas, and WebGL.

[LuchoTurtle]

Having read https://geekyants.com/blog/web-renderers-which-one-to-choose-html-or-canvaskit/,

Choose the html option if you are optimizing download size over performance on both desktop and mobile browsers.

Choose the canvaskit option if you are prioritizing performance and pixel-perfect consistency on both desktop and mobile browsers.

[nelsonic]

Indeed. At this point I just want to experiment with the options and see what results in a faster load time.
the --web-renderer html should result in less JS being loaded because as noted in:
https://stackoverflow.com/a/71148217/1148249
canvaskit is one of the biggest downloads before the page can be rendered. ⏳
So if we can excluded it, we should at least try. 🤞

[nelsonic]

We need to understand if the continuous build/deploy to Fly.io is working. 🤷‍♂️

Minor decrease in Mobile Performance: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwylapp.fly.dev%2F

Need to understand if the build with html worked or if this is still the canvaskit version ...

[LuchoTurtle]

@nelsonic I've implemented the differences between web renderers and added a splash screen on the deployed flutter-phoenix-channels-demo repo and documented how this impacts Lighthouse metrics in dwyl/flutter-phoenix-channels-demo#4.

[nelsonic]

The html renderer made a difference in the simple demo app. ✅ see: switching renderer ...

The "splash screen" while annoying, makes an appreciable difference to the perceived loading time
without a major impact on bundle size. We can get creative with it. But the point is it almost eliminates the performance issue. 🎉

We need to optimise our index.html to show some basic but useful content before the App loads`. ⏳

[LuchoTurtle]

I believe this should be closed now 👍

[nelsonic]

@LuchoTurtle as much as I want to agree, sadly, not even close. 😞
After hand optimising the index.html file to remove all the superfluous CSS and merging #321
Deployed to Fly.io: https://github.com/dwyl/app/actions/runs/4309469656/jobs/7516920496

We get: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwylapp.fly.dev

If we can't do better than 65 on the Performance score, we should basically hang-up our keyboards. 🙅
Don't get me wrong, this is definitely an improvement on the 31 registered above #315 (comment) ⬆️ 🎉
But while we have reason to celebrate, we certainly don't have a reason to close this "research" issue... 🔍

We need to understand how much of the Time to Interactive latency is due to being hosted on Fly.io
and whether switching this to being hosted statically on GitHub Pages will reduce that latency.

@LuchoTurtle very curious how you got 91 for performance above #315 (comment) 😮
When I run the same website: https://dit-tests.web.app on PageSpeed:
https://pagespeed.web.dev/report?url=https%3A%2F%2Fdit-tests.web.app

Did you have 4G throttling turned off? 🤷‍♂️

For comparison: our PETAL MVP has a 99 Performance score:
https://pagespeed.web.dev/report?url=https%3A%2F%2Fmvp.fly.dev

I think our NextAction is to try GitHub Pages for deploying the Web version of the Flutter App.
And then use Cloudflare Pages to load the static files:
https://community.cloudflare.com/t/how-to-deploy-pure-static-html-and-css-site-to-cloudflare-pages/255733 🚀

Side Quest: #322

[LuchoTurtle]

@LuchoTurtle very curious how you got 91 for performance above #315 (comment) 😮
When I run the same website: dit-tests.web.app on PageSpeed:

It's because I'm testing with Desktop resolutions, which is what Flutter Web basically targets.
The numbers of PageSpeed are similar in desktop devices.

Though I agree with you that the web mobile performance numbers are lacking (even if there's an app for it).

[nelsonic]

For future reference and avoidance of all doubt. We only care about Desktop for "completeness".
We expect fewer than 10% of people to use our App on Desktop.
Though we will monitor the stats closely to figure out how to invest our time.
Right now, I am using the MVP mostly on my Mac: https://plausible.io/mvp.fly.dev

But that's only because it's where I spend most of my day. i.e. working on laptop. 👨‍💻
We expect most people who will use the dwyl app to do so on-the-go / out-and-about. 🛒 🏃 🏞️
So we MUST focus 90% of efforts on Mobile. 📱
And within those 90%, 60% on iOS as noted in: learn-flutter#iOS 🍏

We almost never want to test PageSpeed Insights for Desktop
because more than 80% of the people using our App on Desktop will have broadband internet
i.e. the 1Mb Flutter "bundle" (main.dart.js) file is insignificant to them.
But on Mobile ... where network is inconsistent/slow, we care very much about loading times.

So in future, please always test on Mobile. 🙏

[LuchoTurtle]

Visiting https://dwyl.github.io/app/...

The results seem to be similar to that of Fly.io when compared with Github Pages.

[nelsonic]

Yeah, similar perf, but we wouldn't have known without trying. Thanks. 👌
Marginally better so IMO we can phase-out the Fly.io version. ✂️
Unless there's a clear advantage to using Fly.io 💭

[nelsonic]

I see 66 on perf: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwyl.github.io%2Fapp%2F

How do we "Reduce unused JavaScript" on this?

[LuchoTurtle]

I don't know if there's any actionable way of reducing Javascript, it's all built by their Dart Compiler.

The only way that I know that we can control the size of the js output is through web renderers, but we've already been through that on dwyl/flutter-phoenix-channels-demo#4.

Our app is super plain and simple, I don't know where we are not using JS 🤔

[LuchoTurtle]

I mean, even when Flutter's official gallery (which was developed in Flutter) has a performance of 56, it's quite telling that Flutter Web is not meant to have ultra-fast perf scores.

[nelsonic]

indeed. the flutter example has relatively poor web performance. 🐌 🙄
however ... if we inspect the repo that generates the site: https://github.com/flutter/gallery/tree/main/lib/studies
there are quite a few demo apps inside it e.g: https://github.com/flutter/gallery/blob/main/lib/studies/reply/app.dart

A good way to compare/contrast is to look at the amount of Dart code in the Gallery project:

By contrast our App has only 18% Dart code:

The C++ code and CMake is the underlying native code.
The majority of the code in our project is just boilerplate.
So as we increase the business logic (Dart) code in our project we can expect performance to decrease gradually.

I still want to explore the any/all potential options for optimisation.
But we need to be pragmatic about this.

[nelsonic]

70 ... 📈 👌

Deploying the Flutter Web App to GitHub Pages #322 (comment) has improved performance from 65 to 70; 5% is good.

https://pagespeed.web.dev/report?url=https%3A%2F%2Fapp.dwyl.com%2F

I tried to deploy the app using Cloudflare Pages: #322 (comment) but no improvement in perf so not pursuing it any further.

Our next avenue of research is to attempt to reduce the main.dart.js file; it's massive!!
See: #326

[nelsonic]

GOTO: #326