Faster first pageview?

BartVB

A disadvantage of Flarum compared to 'classic' forums is that all rendering takes place on the client. This provides a great user experience when browsing the site but results in a pretty slow first pageview.

The request needs to be answered which takes time, quite a bit of javascript needs to be downloaded, parsed and run and no real content is displayed until all Javascript has executed.

It's a bit slowish on have a fast device and ditto connection but it's quite slow on other devices/connections. More than slow enough to cause visitors to hit 'back' before the site has even loaded.

What would be needed to send a pre-rendered page to first time visitors? I did some quick Googling and there do seem to be ways to make Mithril apps isomorphic. How feasible would this be for Flarum (after it hits stable ? ).

clarkwinkelmann

As far as I know, Flarum already preloads the data along with the page, so no AJAX request is used to boot the page.

Did you make some benchmarking ? Is Mithril the slow part in this ? I'd be curious to know.

I indeed suspect server-side pre-rendering of client side application is not something we will see in core soon. But even as an extension, it should be doable if the technology exists to pre-render Mithril with PHP.

BartVB

True, AJAX is not the problem here.

Hmm, I did a bit more digging (quite time constrained at the moment) and a bit piece of the puzzle seems to be latency between my computer and the Flarum server. That's approx 150ms which adds up.

According to a quick test I'm first waiting 600ms to receive the initial page. Then an additional 600ms is needed for forum-en-*.js to arrive. That makes 1200 ms before anything meaningful can happen.

But I guess I should benchmark with a server with a bit less latency to get a better picture of performance.

A quick fix for Flarum.org would be to either use HTTP/2 to push the CSS/JS resources or use a global CDN for static files. That would eliminate almost 600ms of a (first) pageview.

luceos

BartVB in case you enabled debug the assets compilation runs on every hit. Disable debug to increase performance drastically.

BartVB

The 600/1200ms results were while benchmarking discuss.flarum.org ?

JoshyPHP

I don't know about the first page view but just looking at https://discuss.flarum.org/assets/forum-def494fc.js there's ~966 KB of JavaScript in there. Minify it with Google Closure Compiler (in SIMPLE mode, it's a real shame libraries don't support ADVANCED compilation) and you get it down to 700 KB. Judging by this article, that'll take half a second for V8 to parse it on a mobile or low-end CPU.

As an aside, precompressing the minified file offline (IOW at high compression level) gets it down to 180 KB with zopfli and 148 KB with brotli. Obviously that only affects the time spent transferring it, not the time spent parsing it.

BartVB

It would be great if it were possible to split the JS into several parts/modules. A guest user (without any rights to vote/post/save) probably only needs a fairly small part of all that code. And all code that a guest user doesn't need also isn't needed for the initial rendering of the page.

But I don't have a clue as to how feasible it would be to separate the javascript code like that?

JoshyPHP Those are impressive reductions in size!

Franz

BartVB Toby is working on compiling our assets with Webpack. That doesn't give us these things for free, but they do support code splitting, so splitting up the bundle might be possible in the future.

BartVB

Sort of related: https://github.com/JeroenNoten/Laravel-Prerender
This seems to be a rather course solution, it runs a headless browser to render the page. Sounds slow ? But could be interesting for SEO purposes.

Mainly posting this here so I'll be able to find this again ?