I’ve noticed that Google Chrome says that this Discourse site is using “obsolete cryptography”, specifically RC4 128 bit. @raphael is access to this installation proxied through Jasper, or no? I feel this is something we should address, but I’m not entirely sure where the necessary changes must be made.
Also, the initial SSL handshake required to access this site seems to take a rather long time from my location. Is there any way we can speed this up, for starters I’ll increase the SSL keep alive length once I know where to make this change.
@john not only I improved TLS keepalive and cache, but also but also added OCSP stapling for faster load times. If still not enough, I have also set nginx to use session tickets for handshakes shortcuts, and even to use SPDY experimental protocol for reducing latencies.
I was seeing a TTFB of 5.5 seconds here. If I open Chrome’s developer tools and refresh the page with caching disabled, it takes up to 26 seconds to load the main discourse page fully from scratch, which is a 5.3 MB download spread across 31 requests.
I’ve spent a couple of hours tweaking Nginx’s config file. It now caches any requests for images so Discourse doesn’t have to deal with them, and adds expires headers to them. I also enabled level 9 gzip compression on all css, js and htm files, which reduced the total size of the home page to 3.3 MB. Then, I noticed a whole bunch of .map files (no idea what they’re for) were being downloaded on the home page, so I told Nginx to also compress these. Now, the home page takes 1.3 MB to fully download.
Oh, and I also recompressed our site asset png images with super tight compression.
(if we have load issues, we could look at turning the gzip down from level 9 to something more like level 7).
15 seconds is still quite a long time for a new visitor to wait…
The cpu consumption of Nginx hasnt risen at this stage. However I do agree with your article. My focus yesterday was moving load from Discourse to Jasper, then today I’ll try and figure out how Discourse’s css and JS systems work so I can compress them at the source using the technique in your article.
If we’re only doing it once, I see no reason not to -9 them, though, as it makes hardly any difference to client side CPU requirements.
Nginx is not fixed in discourse VM, it uses docker compiler and everything is recompiled and reconfigured during rebuild. If there is something to do, it’s rather on Jasper, but on the other side, CDN seems to give much more velocity.