Was spending a long time optimizing my CSS, removing plugins, removing redirects, everything I can to improve load times but apparently the main culprits are:
mobile_4-randomcharacters-.css, which contains normalize.css and Pikaday and loads at 1.5 seconds on mobile
and /assets/ember_jquery-randomcharacter-.js which loads in 3.6 seconds on mobile
I have no idea what to do about these files, which having the highest loading time.
Desktop loading is faster, but not great.
Server is on 1 CPU 2 GB RAM 50 GB SSD 2 TB bandwidth on a professional US based server
2 unicorn workers, neither CPU nor RAM are under heavy load, and I dont have many users or plugins
Any ideas? thanks
thank you, PageSpeed Insights says the CPU time (not delivery time) specifically for the second asset was almost 4 seconds, will a CDN like fastly still help with that? I currently use cloudflare with caching, is there a tweak on cloudflare I should use or just add something like fastly on top?!
That is indeed a big asset that will take time to parse and evaluate. As Discourse is a “Single Page Application” that cost is all paid upfront when the user first arrive, and this is a trade-off of our the approach, which is focused on making all the subsequent interaction, typical of forum usage, lightweight.
There are plan for EmberJS to drop mandatory JQuery, which will reduce this payload a fair bit, but we are years away of making this transition in Discourse.
Well, the pagespeed defaults force a Nexus 5X and a 3G connection, which even for Brazil (a third world country) is on the low end for today standards, so real world performance will depend on that.
There is practically no load showing in the server’s stats performance, yet the URL takes ages to load. Clocked 1.2 mins for a non-logged-in visitor on an incognito window, even when quite some components were in cache. The slowest were the OpenSans ttf font files at over a min; after that several .js components took 30 to 45 secs.
I’ll look into caching options, but looking at these components I don’t think all are cacheable. Totally only 730KB data transfer. If all the 3 vCPUs were clocking full then I’d consider moving to a faster server, but with even that showing little to no load I’m just confused.
Is there something that’s waiting on something else before proceeding? Any way to run tests in the server to check health of components like the DB?
Could docker be slowing things down?
