Our site’s speed is very low, we have disabled widgets and extra JavaScript codes but still site has a very low speed, we have scanned our site but the scanner told has to fix some emberjs codes and we don’t want to modify the discourse source code.
How can we speed up our site?
AI 生成的摘要
The discussion revolves around optimizing the speed of the website padpors.com. Initially, Alavi1412 mentioned the site’s slow speed and the fact that they’ve already disabled widgets and extra JavaScript codes.
Falco analyzed the site and pointed out three key areas for improvement:
- Time to First Byte: The site takes 450ms to load, which is slow. Upgrading to a faster server could help.
- Site Size: The site is 2.4MB, which is large. Reducing the size would improve loading times.
- Requests: The site makes 120 requests, which is high. Optimizing images and reducing the number of requests would help.
Falco also suggested that the numerous third-party plugins installed on the site might be contributing to the slow speed.
Alavi1412 revealed that the site is hosted on Amazon Web Service / Micro, which has limited resources. nicatronTg suggested upgrading to a Digital Ocean equivalent tier or a higher-tier plan to increase resources.
Mittineague pointed out that the site has two “should fix” warnings on PageSpeed Insights and suggested moving custom scripts to the body tag and optimizing images.
Pad_Pors mentioned that the site is actually on a t2 small instance with 2GB RAM and 12 CPU hours. nicatronTg suggested trying safe mode to see if plugin-related issues are causing the slow speed.
EducatorWaji discovered that the site has a large number of images, which contributes to the slow loading speed. kemporu pointed out the large number of loaded JavaScript files and their total volume (3MB).
The discussion also touched on the topic list preview plugin, which Alavi1412 discovered loads a lot of images and unknown requests, contributing to the slow speed.
Anil_Gupta noticed that the meta.discourse.org site also has a large payload, with a single JavaScript file standing out at 1.69MB. However, codinghorror clarified that the actual transmitted size is 238kb.
To summarize, the key takeaways for improving the site’s speed are:
- Upgrading to a faster server or increasing resources
- Reducing the site size and number of requests
- Optimizing images and moving custom scripts to the body tag
- Reviewing and optimizing third-party plugins
- Implementing lazy loading and reducing the number of images loaded on the homepage
- Using a CDN to reduce loading times.
Time to First Byte
At 450ms for a anon user, this is not that great. Easiest way to make it better is using a better server with faster CPU.
I get half of that here on Meta.
Site Size
2.4MB for a website is crazy. Reduce that ASAP.
Meta sits at 816KB currently, and that’s somewhat heavy, but we have made it better last year, and will make it better this year too.
Requests
Your site have double (120) the request count of Meta. We know HTTP2 makes it better to have many requests, and saved us from the inline-everything dark ages, but this isn’t an excuse to use 100+ requests to draw a webpage.
Plugin stravaganza
Last time I checked you have more than 10 third-party plugins. Well, as some guy said The best code is no code at all.
If you really want all those cool plugins, well you have to pay the speed price.
How should we do This?
What is the best way to increase that?
Where have you hosted your site?
Can you please tell us your specification of the hosting account?
Amazon web Service / Micro.
Then the poor loading time is not releated with hosting issues. Anyway, you should try to increase the RAM, as you have significant amount of users in your forum.
Maybe not the only cause, but PageSpeed Insights
has two “should fix”
If you have custom script in <head> maybe try it in </body> instead?
Maybe this is using full weight images resized with CSS?
Or is it this plugin?
https://meta.discourse.org/t/topic-list-previews/41630
I’m sorry if I’m reading this wrong. Are you saying that you’re on the AWS t2.micro instance size? The instance size with 1GB of RAM and 1 vCPU? You’re probably hitting CPU constraints, if not RAM constraints due to your plugin load.
From the AWS docs:
T2 instances are Burstable Performance Instances that provide a baseline level of CPU performance with the ability to burst above the baseline. The baseline performance and ability to burst are governed by CPU Credits. Each T2 instance receives CPU Credits continuously at a set rate depending on the instance size.
With a Micro instance, you’re getting 6 CPU credits/hour, and that’s not great. You’d probably be better off migrating to the Digital Ocean equivalent tier, which is $10/mo, or even the DO $20/mo tier that offers double the RAM.
Thanks for explaning. I have already mentioned it to him, but I was busy At that moment.
@Alavi1412 should consider this and make neccessary changes
Sorry sir for the not-updated information, it’s on a t2 small instance, which is 2G ram and 12cpu/hour.
I don’t thing we need more cpu/ram with the amount of traffic we have, currently. is there any way to measure this?
You could try safe mode and see if the network conditions improve at all. That would tell you that your plugins are a big cause. Rafael’s points are still very valid. You need to have a beefy box if you’re going to run tons of plugins to compensate for the increased load.
regarding your hint about caching:
the warning is about 3 google analytics resources, and two fonts.
- we have set the analytics via the admin setting panel, how can we add expiry date to these resources?
- how can we add expiry date to other resources? as the answers found via google address the htaccess file, which doesn’t exist in the discourse folder. do you have any idea how I should that?
Thanks for the advice, but I can’t understand what is this size for?! as even when the plugins are deactivated, our site size is only slightly different from this number! how can one find out what is the size for?
Thanks in advance
Well, Chrome DevTools (F12) gives you the size of every asset.
I would like to say, somehow try implementing Lazy loading and load only a few images and few topics, Now your site loads 11*3 = 33 topics in one go. Reduce it to load about 6 topic with images in the homepage. Which will reduce the initial loading images. Doing so will reduce about 1 MB of page size. Hope you will figure it out
Photos can be removed. I am concerned
1. number of loaded js files
2. their total volume. 3MB! that’s a lot.
Yeah! @kemporu, I didn’t notice that. That is too much for js files. It is enough to make old system and old browsers go unresponsive
But, look at the time taken to load the images, it is way more than those js files.
Way more?! If my math is right, that’s like 23 minutes 
If that is with the Topic List Previews plugin disabled, that leaves the avatars?
Is the site using a CDN?
I guess not! If they had used CDN’s the loading time might have been much better.