Ho passato molto tempo a ottimizzare il mio CSS, rimuovendo plugin, reindirizzamenti e tutto ciò che è possibile per migliorare i tempi di caricamento, ma a quanto pare i principali responsabili sono:
mobile_4-randomcharacters-.css, che contiene normalize.css e Pikaday e viene caricato in 1,5 secondi su mobile
e /assets/ember_jquery-randomcharacter-.js, che viene caricato in 3,6 secondi su mobile
Non ho idea di cosa fare riguardo a questi file, che hanno i tempi di caricamento più alti.
Il caricamento su desktop è più veloce, ma non eccellente.
Il server ha 1 CPU, 2 GB di RAM, 50 GB di SSD e 2 TB di banda, ed è ospitato su un server professionale negli Stati Uniti.
Ci sono 2 worker Unicorn, né la CPU né la RAM sono sotto carico pesante, e non ho molti utenti o plugin.
Qualche idea? Grazie.
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.
Non c’è praticamente alcun carico visibile nelle statistiche delle prestazioni del server, eppure l’URL impiega un’età a caricarsi. Ho misurato 1,2 minuti per un visitatore non autenticato in una finestra di navigazione in incognito, anche con diversi componenti già nella cache. I più lenti sono stati i file di font OpenSans ttf, che hanno superato il minuto; successivamente, diversi componenti .js hanno richiesto da 30 a 45 secondi.
Valuterò le opzioni di caching, ma osservando questi componenti non credo che tutti siano cacheabili. In totale, il trasferimento dati è di soli 730 KB. Se tutte e 3 le vCPU fossero state al 100%, avrei considerato di passare a un server più veloce, ma dato che mostrano poco o nessun carico, sono semplicemente confuso.
C’è qualcosa che sta attendendo un’altra risorsa prima di procedere? Esiste un modo per eseguire test sul server per verificare lo stato di salute dei componenti, come il database?
Docker potrebbe essere la causa del rallentamento?
