New feature!

Now the lab gives you a detailed look at what's taking space in your javascript files.

"Flarum Core" and "Flarum TextFormatter" are the base components of Flarum, so you can't do much about them. Then you'll see each extension sorted from the bigger impact.

We can notice that there's rarely one extension having a huge impact (except Password Strength and EmojioneArea at 830 and 650 kB respectively). But it quickly adds up when you have many extensions.

Extensions with a triangle are those that were not compiled for production before being published. If the author re-compiles the extension for production it will take less space. @askvortsov is already on the case for his extensions by the way.

The lab is not going to offer any recommendation regarding assets size. It's up to you to decide what you do with this information.

I plan to also add details about the language and CSS files in a future update.

    Littlegolden yes it could be. Or maybe there was a sudden spike in traffic on one side or another.

    If it happens every single time it's a bit concerning. If the javascript takes more than 20 seconds to be downloaded.

    The lab is hosted on DigitalOcean in Germany.

        Hi @clarkwinkelmann
        do you sugget to activate Opportunistic Encryption on cloudflare?

        Opportunistic Encryption allows browsers to benefit from the improved performance of HTTP/2 by letting them know that your site is available over an encrypted connection. Browsers will continue to show “http” in the address bar, not “https”.

          Gatsu I'm a bit confused why you would want to make https optional at all: in 2020, every site should be using encryption. I'm assuming this is moreso a leftover feature, and not really something you want for the modern age.

            Gatsu I suggest using the Full(strict) + Always use HTTPS + HSTS with preload options.

            I see Opportunistic Encryption is enabled by default, so I wouldn't bother touching that setting. As I understand it has no effect if you force HTTPS anyway.

              clarkwinkelmann Now the lab gives you a detailed look at what's taking space in your javascript files.

              It's your fault! 😂😂

              clarkwinkelmann Flarum versions 10 to 12 are shown as "beta 10/11/12" because there's no way to tell them apart from the homepage source code. A more advanced detection is planned, but I can't say when it will be available.

              For future version, wouldn't it be useful if Flarum itself exposed the version? It's not a particularly sensitive information IMO, pretty much every forum platform out there exposes the version in the footer or in the source code.

                    matteocontrini For future version, wouldn't it be useful if Flarum itself exposed the version? It's not a particularly sensitive information IMO, pretty much every forum platform out there exposes the version in the footer or in the source code.

                    While many forums do share the version someplace it's generally a bad idea. It's not going to cause massive amounts of abuse no. But lets say that we fix a major security issue in say 1.1.5 and the versions affected are everything back to version 1.0.2 (random version numbers) then in theory attackers could create an exploit and then do a massive scan of all forums that are within that range and attack them all quickly, effectively and with extreme precision.

                    By not including the version number in the code or display it means that the attacker has to try attacking ALL Flarum installs, regardless of whether it's updates or not. It probably wouldn't slow them down all that much, but it might be discouraging to them to see hundreds of sites return with nothing promising and they might just stop trying.

                        tankerkiller125 yeah but the version is actually still detectable even without having the version exposed, it's just a matter of finding a specific line of code that is present in a version and not in the previous (or next?).

                        It could also be an option, for those that don't want to expose the version.

                          SezginYILDIRIM there is an encoding problem on your homepage, most likely inside of the preloaded discussion data. It's not valid UTF-8.

                          I have improved error handling for invalid encoding, now it should at least provide an error message. Previously the database requests would fail because it was trying to insert the data in MySQL. This left the scan in an unfinished state.

                            clarkwinkelmann If it happens every single time it's a bit concerning.

                            Yeah... it happens every single time... My server is in Beijing.

                              7 days later
                              19 days later

                              datitisev I have added this to .htaccess:

                              <IfModule mod_rewrite.c>
                              RewriteCond %{HTTPS} !=on
                              RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
                              RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L]
                              </IfModule>

                              but always error 🙁