Some thoughts for extensible Service Worker support

huoxin

Flarum 2.x introduced code splitting and lazy loading, which are definitely useful for reducing the initial bundle size and improving first page load times.

However in practice, I noticed there are some trade-offs as well.

E.g. the composer/text editor
On a fast connection, the difference is barely noticeable. But on a slower connection, when a user clicks Reply, they still have to wait for the editor's JavaScript chunk to be downloaded before anything appears. Even if it's only a short delay, it can give the impression that the forum is laggy.

Fast connection:

Slow connection (throttled to 3G using browser dev tools):

One idea I had was to use a Service Worker to precache commonly used lazy-loaded chunks, such as the composer/editor. That way, while the user is browsing the forum, the Service Worker could quietly download those chunks in the background so they're ready by the time the user needs them.
The same idea could also be useful for other assets, such as emoji/Flamoji resources.

However, while looking into this, I noticed that the current Service Worker infrastructure isn't really extensible. As far as I know, the most commonly used extension that registers a Service Worker is the PWA extension (either the FoF version or the original one). It registers at /sw, but browsers only allow a single Service Worker to control a given scope (such as /). That means whichever extension registers first owns the Service Worker. If another extension wanted to leverage a Service Worker, it would conflict with the PWA extension.
To make Service Workers more useful across the ecosystem, I think the infrastructure itself probably needs to become extensible.

So I opened this proposal and hope to get some thoughts/options on the best way to solve this.

One of the ideas is to introduce a Extend\ServiceWorker API that compiles multiple JavaScript files into one sw.js. (something similar to how js and css in flarum is loaded currently) But where should we build it?

A brand new service-worker-manager extension that other extensions depend on?
Built into Flarum core? (not necessarily a core feature, but feel like fairly low-level infrastructure, so, maybe?)
Refactor fof/pwa so it acts as the Service Worker manager and exposes the extender API (similar to option 1).

Hope to hear your thoughts ❤️

Forogramero

huoxin The same thing happens in my forum since the beginning. When I create a post and click publish, it takes 8 to 10 seconds for it to actually appear as a published post. It also happens with comments (posts). I'm using version 1.18. Now I realize it's related to the composer/text editor.

huoxin

Forogramero Thats a complete different issue, the lazy loading of components in only introduced in 2.x, so it does not affect any 1.x version. And the main issue I was talking about was the opening of the composer/text editor (Edited on top with the images so it is clearer)

Although having cache from the service worker can somewhat help loading speed in 1.x also? (would need to port back to 1.x) It wont solve your problem of slow speed when publishing post, more likely your bottleneck is somewhere else e.g. database or IO of the server etc... (cant say much without any log)

Forogramero

huoxin It's not the database, not the server, for sure. It got to be something else. Thank you for replying.

luceos

Forogramero your issue is caused by flarum sending emails to followers. You probably don't run a queue, so the more people will need to be informed by email about a new discussion or reply, the longer it takes for the page to load as the emails are sent in the same process to store the post. With a queue, this is processed without user interaction. The worst part is, if you don't tackle this, at some point your http requests will simply time out and email sending might not completely finish.

On topic: I think this is a great idea. Just unsure whose responsibility it should be.

Forogramero

luceos What do I have to do to fix this situation??
And thanks for the response...

Forogramero

luceos I have noticed that my email configuration (the 'noreply@... ' part) was not well configurated.

Forogramero

luceos I got it. I have to create a queue (Cron job).

DaleZ

Quite in line with this. We currently waste a lot of time to do nothing, but we could have had the time to fetch scripts in background. However, personally speaking, I suggest to be careful with Service Worker.

Service Worker is powerful, but also because of that, incorrectly written code could break the whole forum. And to my experience, it’s usually hard to reverse the problem when something went wrong. (Even sw’s own life cycle is a hot potato, too)

The another important point of making an extensible SW is whether it may be too complex. Through SW we can do some things by dealing with its events - proxying network requests, triggering notifications, and so on. It’s worth to notice that all of these events can only be processed once per event. That’s to say, we may introduce the possibility to make extension conflicts in an another thread…(We're already having a headache from extension conflicts in the main thread, btw)

We should still admit, sometimes it’s necessary to use Service Worker, but in this case, I’m concerned that it’s a sledgehammer to crack the nut. I had tried to add the ability for flarum-pwa to cache assets in cache storage(askvortsov1/flarum-pwa58), but finally I had to stop because it became a big mess.

I’m not about to disappoint us. In fact, I think browsers have already had a reliable cache & preloading mechanism for us to use: <link rel="preload"> and <link rel="modulepreload">.

https://developer.mozilla.org/docs/Web/HTML/Reference/Attributes/rel/preload
https://developer.mozilla.org/docs/Web/HTML/Reference/Attributes/rel/modulepreload

It’s easier to control(examples are provided in the links above). What we need to do is just append elements ahead of time to trigger preload. If browsers have cached assets we want, they’ll be ready at once. If not, browsers try to fetch them silently so they will very possibly be available before we finally need them. For more precise control, only preload composer when users enter a discussion, only preload login modal when users are not logged in, etc. It’s also easy to pack a helper function, making it easier to add this element.

Just some of my own ideas, for references only. Maybe the topic will be more focused on faster assets loading, instead of the specific SW extensibility…Anyway, thanks for reading. 🙏

Forogramero

@DaleZ @luceos"#1376 This is the way I inally fixed the 10–15 second delay when posting! (Queue + Cron setup). Right now, users can post almost instantly:
---

The problem:

Every time I posted something, the page would just hang there forever. Turns out, as Luceos suggested, Flarum was trying to send email notifications to all followers in real-time, and since I'm using Gmail SMTP (which is pretty slow), it was blocking the whole process. The more followers a discussion had, the longer it took.

What I did (step by step):

1. Changed the queue driver in config.php

I opened my config.php file and added this:

'queue' => [
    'driver' => 'database',
],

This tells Flarum to use the database for queuing tasks instead of processing everything immediately.

2. Installed the Database Queue extension

I ran this command via SSH:

composer require blomstra/database-queue:"*"

Then activated the extension in the admin panel and ran:

php flarum migrate

This created the necessary queue_jobs and queue_failed_jobs tables in my database.

3. Set up the Cron Job (this was the tricky part)

I'm on Hostinger shared hosting, so I had to figure out their cron job system. Here's what worked for me:

First, I created a small script file called cron-flarum.sh inside my Flarum root folder (where config.php is):

#!/bin/sh
cd /home/YOUR_USERNAME/domains/YOUR_DOMAIN.com/public_html && /usr/bin/php flarum schedule:run > /dev/null 2>&1

(Replace YOUR_USERNAME and YOUR_DOMAIN with your actual details!)

Then I gave it execution permissions:

chmod +x cron-flarum.sh

In the Hostinger panel (hPanel), I went to Cron Jobs and created a new task:

Type: Custom
Command to run: /bin/sh /home/YOUR_USERNAME/domains/YOUR_DOMAIN.com/public_html/cron-flarum.sh
Schedule: Every minute (* * * * *)

Important: If you try to run the command directly with && or > symbols in Hostinger's cron panel, it might fail. That's why I used the .sh script approach – it's cleaner and more reliable on shared hosting.

4. Cleared the cache

php flarum cache:clear

The result:

Now when I check the admin panel, I see:

Scheduler: Active ✅
Queue Driver: database ✅
Queue Overview: Running ✅

And the best part: posting is now almost instant! It takes less than 2 seconds. The emails get sent in the background by the cron job, so users don't have to wait anymore.

One thing to watch out for:

Environment:

Flarum 1.8.11
PHP 8.2.30
MySQL 11.8.8-MariaDB
Hostinger shared hosting

Hope this helps someone! – I spent way too much time figuring this out, so happy to save others the headache. 😅

And thanks to you bc I addressed this situation thanks to your post. And thanks to Luceos too, he did in fact pointed this out correctly.

And blomstra/database-queue , what a great extension. Thank you! 😀

Deepseek IA helped me all the way out!