Closed nelsonic closed 1 year ago
Should a different repo be created for this? Or should we create another workflow in this one?
@LuchoTurtle good question. π
Strong preference for using this repo and creating a new GitHub Actions Workflow
Typically the way we have done GitHub Pages
deployment in other projects
is with a gh-pages
branch that and a workflow to build
the static content e.g:
Fairly certain you can use this action: https://github.com/JamesIves/github-pages-deploy-action (we're already using it) to some of the boring bits. π
Please let me know if you want to pair on this. π₯ π§βπ» And if you want to spend a couple of hours on documenting what you learned, π please do so in: https://github.com/dwyl/learn-github-pages |> https://github.com/dwyl/learn-github-pages/issues/2 π
Capturing the BEFORE
pictures for reference π·
so that we can evaluate how much faster having the Flutter Web App
π±
is on GitHub Pages
than on Fly.io
ποΈ vs. π ... π€·ββοΈ
Running Lighthouse
in the Chrome
Dev Tools is basically "Perfect Conditions":
A far more realistic test is running it online: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwylapp.fly.dev
For reference the dwyl.com
static site is hosted on GitHub Pages
and currently gets a 93
perf score:
https://pagespeed.web.dev/report?url=https%3A%2F%2Fdwyl.com
This should be our lower bound. i.e. if we go lower than this for the app
we need to rethink things.
Ideally we should spend as much time as needed to get it up to 100
.
Yes, it may feel like an "arbitrary" goal, but if we achieve 100
for everything it means we aren't wasting people's time. π
Will work on this π
Though I feel the need to point out that comparing a Flutter Web
app with dwyl.com
is not necessarily a fair comparison, as the latter was made with JS + Tachyons and we already know the shortcomings of using Flutter Web
.
Though this doesn't mean we shouldn't strive to go for near-native performance on all fronts π
I'm stumped on why Github Pages don't properly serve the built files from Flutter Web
.
When I run python -m http.server
locally, after running the exact same command from the workflow (flutter build web --release --web-renderer html
), it shows the web app correctly..
@LuchoTurtle yes, the hand-crafted dwyl.com
is significantly smaller
than even a "Hello World!"
(counter
) Flutter
App ...
it's not meant to be comparison, just a reference.
GitHub Pages
is already working well for us. β
But ... we need to do everything we can to get performance
up to 100
on the Flutter Web App
.
Even if we have to use "smoke and mirrors" ...
i.e. get creative with a "fake door" that only starts loading the Flutter App
after the page is fully interactive.
@LuchoTurtle it's a good sign that it works on localhost
. π
The necessary files appear to be there on the gh-pages
branch: https://github.com/dwyl/app/tree/gh-pages
The config for GitHub Pages
appears to be correct.
https://github.com/dwyl/app/settings/pages
The fact that the index.html
loads suggests that something is working. π
Guessing you've done a bunch of googling ... π
Please share links to what you've looked at. π
The _flutter undefined error
seems to be people trying to serve the web
folder instead of build/web
.
I'm doing so with the github-pages-deploy-action
in the folder param.
- name: Deploy to Github Pages
uses: JamesIves/github-pages-deploy-action@v4
with:
branch: gh-pages # The branch the action should deploy to.
folder: ./build/web # The folder the action should deploy.
And I'm sure the folder exists because it's shown in the workflow.
I've checked many links, including the ones below.
https://www.reddit.com/r/flutterhelp/comments/xf4yyl/flutter_web_app_build_successfully_but_is_not/
https://stackoverflow.com/questions/73815269/flutter-web-why-it-is-getting-404-error
But this seems like Github Pages is not serving the files correctly. Because flutter.js
definitely exists in the workflow, so it shouldn't be undefined.
Could you try pushing everything to the branch
and then selecting ./build/web
in the pages config: https://github.com/dwyl/app/settings/pages ?
You can't do that in the page config
they only allow root
or under docs
.
The source branch can be any branch in your repository, and the source folder can either be the root of the repository (/) on the source branch or a
/docs
folder on the source branch.
As per https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#static-site-generators, they use Jekyll
to serve the files. Perhaps customizing this behaviour might be a solution.
Tried switching to /docs
:
And updated the workflow to place it there:
- name: Deploy to Github Pages
uses: JamesIves/github-pages-deploy-action@v4
with:
branch: gh-pages # The branch the action should deploy to.
folder: ./build/web # The folder the action should deploy.
target-folder: docs
But it yields the same page :/
Good catch. iThought it was more permissive than that. Ok. then you're already on the right (only viable) track. π
A bit of Googling suggests a more targeted approach: https://github.com/bluefireteam/flutter-gh-pages π€
Is this error worth investigating?
Error with Permissions-Policy header: Origin trial controlled feature not enabled: 'interest-cohort'.
A bit of Googling suggests a more targeted approach: bluefireteam/flutter-gh-pages π€
I guess I'll give this a whirl.
Is this error worth investigating?
Apparently not -> https://stackoverflow.com/questions/69619035/error-with-permissions-policy-header-unrecognized-feature-interest-cohort
Tried using bluefireteam/flutter-gh-pages but it's still not working. The same error appears...
Uncaught ReferenceError: _flutter is not defined
at (index):42:7
I'll revert the changes and try to use .nojekyll
file.
Maybe .nojekyll
won't make a difference, as per https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/.
This should only be necessary if your site uses files or directories that start with underscores since Jekyll considers these to be special resources and does not copy them to the final site.
Hmm ... this is very peculiar.
Going to populate https://github.com/dwyl/learn-github-pages now.
Re-opening just to configure Cloudflare subdomain π¨βπ» β³
loading ... https://dash.cloudflare.com/login?lang=en-US β³
https://github.com/dwyl/app/settings/pages
Viewing the app at: https://app.dwyl.com/
@LuchoTurtle we're back to having the 404
on the logo and other files.
So looks like we need to update some config again. π
https://app.dwyl.com is working thanks to #324 thanks for reviewing+merging @LuchoTurtle β
Deployment worked without any issues: https://app-abz.pages.dev/#/
No improvement in perf: https://pagespeed.web.dev/report?url=https%3A%2F%2Fapp-abz.pages.dev%2F
So I don't think it's worth pursuing this further (for now ...) π
Disabled the Cloudflare pages deployment integration: https://github.com/organizations/dwyl/settings/installations/34861696
As noted in https://github.com/dwyl/app/issues/316#issuecomment-1439717058 and https://github.com/dwyl/app/issues/315#issuecomment-1450229246 π¬ deploying the
Flutter Web App
toFly.io
has proved to be aperformance
fail. πAs noted by @LuchoTurtle in https://github.com/dwyl/app/issues/315#issuecomment-1442235354 it
should
be possible to get a90+
PageSpeed
(LightHouse
) performance score for aFlutter Web App
... πHowever I've not been able to replicate the results on the
PageSpeed Insights
site: https://pagespeed.web.dev/report?url=https%3A%2F%2Fdit-tests.web.app So that's something we need to understand first. π How do we ensure that thePageSpeed
results are consistent? Can we run the tests as aGitHub Action
and save the results somewhere we can review them? π€Todo
Flutter Web App
toGitHub Pages
-> #323app.dwyl.com
points to: https://dwyl.github.io/appThis looks like a decent starting point:
Why This Matters?
Why are we making such an effort on page load time instead of focussing on building our
App
? π€·ββοΈ I don't see this as "not building the app";DevOps
is about delivering theApp
. π Rather I see this is as complying with the first point on our Manifesto. π If we invest weeks of our Dev time in building features π§βπ» β³ and then theApp
takes ages to load forpeople
viewing it for the first time, π it gives them a terrible first impression. π’I'm very happy to pick this up myself. β³ But if anyone
else
wants to help, it's much appreciated. π