site: exchange Dropzone with Pausly

[enyo]

I’m the author of Dropzone.

First of all: thanks a lot for adding me to the showcase! That’s awesome.

I have been working on another project that I think is more fitting though. Pausly is completely written in SvelteKit too (hosted on Vercel, with Supabase as a db) and has been fully migrated to v1.

It uses SSR, has server side authentication support, and uses actions to handle all user interaction. All in all I think it’s a better showcase.

I removed Dropzone so that there are 8 showcases, but if you prefer to keep dropzone in the list, I’m also very happy with that, and can revert the commit where I removed it.

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 5515040e7c4b62d7ea4e94fc90980147bb40583f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rich-Harris]

hey! thanks for the PR — Pausly looks awesome. One of the goals for the showcase is to include sites that have excellent Lighthouse scores — not because we're great believers in Lighthouse (it's a useful diagnostic tool, but it has broken the brains of an entire generation of web developers; a prime example of Goodhart's law), but because unfortunately many people judge a framework on the basis of Lighthouse scores without understanding the subtleties behind them.

One of the reasons we were keen to include Dropzone is that it gets excellent Lighthouse scores. Unfortunately Pausly doesn't score as highly. One of the major factors appears to be the images like https://pauslyapp.github.io/images/exercises/bad-posture-forward.webp. If these were treated as imported assets rather than linked from GitHub Pages, they would be cached immutably. In some cases they could also be made smaller (this is something we'd like to make easier in a future version with better image tooling).

It's possible that there are other factors that could be addressed (Lighthouse doesn't seem to love logrocket, for example) though it's hard to know without working with the source code.

Is there any chance you'd be able to look into some of those Lighthouse recommendations?

[enyo]

@Rich-Harris oh yeah sure! I was going to work on that anyway, so if that’s a requirement for the showcase I’m happy to take care of it right away.

[benmccann]

@enyo I've written up some tips for image optimization, which will automatically build and serve smaller .avif images to browsers that support them in addition to making them cachable (the caching will help users, but probably not your lighthouse scores). Feel free to let me know if there's any other tips I can provide on setting up image optimization

[enyo]

I got it to 88. I’ll continue working on the score tomorrow. Of course I’ll try to get as high as possible, but do you have a threshold?

[benmccann]

PageSpeed Insights is unfortunately pretty variable , so it's best to run it a few times. I ran it twice and got 69 and 71.

I don't think we have a specific cutoff. I've seen a number of sites get high 90s, but if it were regularly scoring 88 that'd probably be fairly good.

[enyo]

@benmccann I’m banding my head against the wall here. I don’t know why I got 88 at one point and now it’s so low. It got it back up to 84, but I’m kind of stuck here.

I tried loading all external JS (like sentry) in an onMount() with await import() but apparently lighthouse still counts it.

I don’t understand why lighthouse gives the score for all JS loaded, when this is the reason I use SSR in the first place. Do you maybe have a hint here?

If I disable CSR for the landing page, I get a 99 score. Isn’t that the same score I should get when the client is hydrated?

[Rich-Harris]

If I disable CSR for the landing page, I get a 99 score.

This likely indicates that the culprit is either Svelte's hydration, or third party scripts/modules that are imported by your app. The DOM is small (roughly the same size as pages on https://kit.svelte.dev, which Lighthouse views favourably) so my hunch is that third party scripts are to blame. One diagnostic approach could be to just remove sentry et al altogether to get a baseline, and then reintroduce them.

It's possible that something like Partytown could help, and if so maybe there's stuff we could do to integrate it in a more turnkey fashion.

[benmccann]

Have you tried lazy loading Sentry? https://docs.sentry.io/platforms/javascript/install/lazy-load-sentry/

[enyo]

@benmccann I have actually already completely removed sentry. One huge part is now supabase, that I can’t seem to be able to reduce. But I’m getting there.

[enyo]

May the performance gods have mercy on me.

At this point it’s very difficult for me to get a higher score, because of supabase. If perf is still an issue here, I’ll need to start working on their clients, because they load too much eagerly and I can’t lazy load the whole lib because it determines the user authentication state and I can’t (don’t want to) postpone that.

[enyo]

Oh man. I just saw that half the time the score is about 87 or similar. I'll try to continue finding ways to improve that.

EDIT: It is consistently over 93 now... but you never know. I’ll continue investigating if I can improve performance, especially with supabase. Maybe it’s already good enough to be merged though.

[benmccann]

Nice! That's a big improvement

Regarding supabase - I wouldn't expect you'd need to load it on the client at all. I'm not exactly sure what page elements you'd fetch from a database. Maybe the "New in Rotation" section? You could create a +page.server.js or +server.js which fetches from the database and then you'd only need to include the Supabase client on the backend. I'd also expect you could prerender the homepage.

[enyo]

@benmccann the reason I need supabase is for authentication. It needs to be loaded initially to maintain the authentication state, and handle things like “magic link” authentication where it will parse the URL and see if there is an authentication token in there. It also checks that when a user logs in, in another tab, the current tab will be updated to reflect the authentication status as well. So unfortunately it’s not so easy to remove without making the landing page completely ignorant of authentication state which is something I hope I can avoid.

I can’t completely prerender the page either, because it contains authentication state info. If I’m not mistaken, it wouldn’t help with the performance score either because it will wait for all the JS to be fully downloaded anyway.

What I am currently looking at, is if I can only include supabase if the user is authenticated. Maybe I’ll get somewhere.

[benmccann]

Ah, thanks for explaining! I do still think you could probably move it to be used only by an API URL that returns a JSON response to the frontend, which would make it so that it doesn't have to be loaded by the client

[enyo]

Finally got it consistently over 95

[enyo]

I managed to conditionally load supabase on the client when needed. It was a bit tough because so much of the App depends on supabase (for example: there is a store in the layout context, that loads new achievements and subscribes to changes, so they can be shown immediately in an overlay. This now needs to conditionally load only when the user is signed in)

I completely understand why you want the score to be high, but it was mostly useless for the end user because the site is also fully SSR, so the few seconds that can be gained when loading the js don't really impact the user. I wish PageSpeed would take SSR more into account.

Anyway, feel free to merge if you're happy with the score now :)

[dummdidumm]

Yeah this is one of the reasons why I think Lighthouse is far from a good tool yet. It says it measures TTI when it actually measures "time to all javascript I detected eagerly is loaded and initialized".

[Rich-Harris]

amazing work! thank you 🎉