Help me speed up HostingDiscussion' WordPress-based news site

Artashes

Artashes

Administrator
Staff member
Let it serve as a real life use case on how to make a very slow WordPress lightning fast. Everything we do will be shared publicly so that others who may experience the same issue can hopefully resolve theirs by using any of the below tips.

In a nutshell, here is the problem:



A little more details:

We just launched a daily news outlet https://hostingdiscussion.com/news/ covering cloud and web hosting industry. It is based on WordPress. Unfortunately, we've been struggling with site's responsiveness (takes waaaay too long to connect), as well as the speed with which the pages are loading after we finally get on the site. 🐌 Everything takes TIME. Time we don't have. Besides damaging our chances to rank well, it's hurting the user experience (that never sits well with me). At this point I come to you for help. Whether you are a web hosting professional with WordPress optimization experience, a WordPress developer, a SEO expert — if you have a suggestion what we should do in order to improve and/or fix this, I'd greatly appreciate it, as would everyone else here.

By no means am I a developer or even skilled to understand technical recommendations, but I do have access to a developer who can help along. All of the things we discuss here will be shared with him and results posted.

Let's make a great story out of this.
 
Before public launch, Conor (aka @bigredseo) made a few great suggestions, privately. It is important to share those as a starting point. With minor edits, but without taking the key idea:

1. Some of the speed issues came from one image that I posted. It was a .png file 5.3MB in size, whereas the the entire page was only 6.3MB. There was also a "fetchpriority=high" being used, so that image must load before anything else. It was a major problem, especially that there was no reason to set a priority, as it's beyond the scroll area anyway. The image that's not properly optimized is killing performance.

✅ With a bit of a clash with Elementor (fetchpriority was still loading even after disabling it through Elementor), Conor pointed us to this piece of code, which worked:
gist.github.com

Disable WordPress core fetch priority

Disable WordPress core fetch priority. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com gist.github.com

2. The site wasn't loading with HTTP/2, which allows for multiple TCP requests to download at the same time.

✅ I've requested my hosting provider IO Zoom to enable HTTP/2 and that alone dramatically improved things, not only for WordPress, but XenForo as well. This post was about exactly that.

3. Also, it seems that the first column must completely load before starting the 2nd and 3rd columns. So there must be a priority item in there too. Since the 2nd and 3rd columns show less information anyway, you may want to define that those two columns start loading first, then load the main one.

❌ Have not addressed this yet.

4. WebP images need to be done.

✅ Done

5. There's also lots of CSS loading that doesn't need to load, but that's a different topic

❌ No solid knowledge to go over this yet.
 
From what I'm seeing, it's a combination of slow initial response time (TTFB, if you like) and a large amount of content being transferred. Interestingly, it seems as though the transfer of HTML is quite large.

You know what solves both of those issues? Litespeed ;) Wordpress is a beast as a standalone product, and then you're adding plugins which use a lot of resource and sometimes are poorly coded. What plugins are you utilising?

There are other issues too but nowhere near as significant as what I've just mentioned, those two are the main blockers of slow loading as far as I can see. I would be tempted to try Litespeed with the Litespeed Cache plugin then retest performance, and see how it goes - then look at fixing other issues.

What type of hardware do it run on?

Serious proposal because I'm also genuinely interested to see the difference, but drop me a message and I can set you up on one of our USA servers with Litespeed, with a staging domain or something similar - if you're interested, no obligation, just to show you the difference of Apache vs Litespeed.

KeyCDN's website speed test has been running for 10+ minutes so far and still hasn't returned a result. 😅
 
Hello @Artashes,

We've experienced similar issues or just errors, after errors with old legacy themes.

We work closely with a WP developer and they use there own scan tool which will pick up on information from your WordPress installation and report back with any issues with your wp installation.

As you requested some support with your WP site, I've run a scan on your WP site for hosting discussions.

I've DMed you a slightly redacted copy of the report as i don't want to reference the website scan tool directly.

It appears from the scan the main issue is with the child themes which are slowing down the page load times significantly.

Let us know.
 
Few things we tried:

Minify CSS
Removed unused CSS
Removed unused themes and plugins (over 20 of them)
Cache implementation WP Rocket (switched from NitroPack)

It helped (I am passing Core Web Vitals for desktop version, but not mobile). Once the page starts to load, things are much quicker to load. However, it is the initial connectivity to the page that still drives me nuts, it takes seconds before the page content starts to load.

How can it be that www.hostingdiscussion.com loads lightning fast, but a folder www.hostingdiscussion.com/news/ takes seconds to establish a connection with, when it lives on the same server! 😣 What could possibly be the problem with the slow initial response time?
 
Hi,
The initial load delay for the /news/ folder may be due to slow database queries, server response time, or plugin conflicts. Ensure the database is optimized, check for plugin issues, and verify your CDN configuration. Additionally, inspect for any redirects or third- party scripts that could be slowing down the connection.

James ;)
 
I tried a wordpress plugin called Smush and it helped increase my speed for my blog by compressing images. It might help.
 
James171 said:
Hi,
The initial load delay for the /news/ folder may be due to slow database queries, server response time, or plugin conflicts. Ensure the database is optimized, check for plugin issues, and verify your CDN configuration. Additionally, inspect for any redirects or third- party scripts that could be slowing down the connection.

James ;)
Click to expand...
How does one usually fix that part?
 
Artashes said:
How does one usually fix that part?
Click to expand...

Query Monitor is a good plugin which shows the database queries that are being made as you're loading a page as well as how long the query took. When logged into wp admin it shows in the toolbar how long each page took to load, if the timing looks high you can click into it for more detail and drill down into what is happening.

It's a very useful tool, but takes some time to understand... and remember to deactivate/uninstall it once finished as it can slow down your site further.
 
Artashes said:
How does one usually fix that part?
Click to expand...
For slow database queries - make sure that the /news database is on it's own separate database. Depending on the host, you may be able to view the traffic and requests headed to the database. Optimize the database by removing old info, any sample/demo data that was imported, and then check the sizes of the tables. If there's a lot, you may need an upgraded plan for better hosting.

As far as the mobile end of things, the "Today's Storystream" is loading first, then the "Featured" loads, but then the "Featured" takes the primary spot on mobile. So it's loading in the wrong order if you want the Featured to be first, and that's going to delay the display.

The page that loads doesn't have any YouTube videos, yet you're loading scripts to show videos (unused scripts). This may need to be removed if you're not planning on YouTube videos in the main feed.

Also, completely unrelated to speed, but the /news is being blocked for search engines. In the "meta robots" section, it's defined as "noindex, nofollow". That'll need ot be changed if you want to show on search engines.

A way to get more details on just what's slowing the page is to add in console commands on various sections.

In the code, you can add the following before a section:
console.time("Request")
Then add the following after:
console.time("complete")

You could do this on anything from database request sections, page display, columns, and specific content. It will narrow down exactly where all the time is spent on the page. It's a lot of detailed work, but if you're going hard-core on reducing speed even further, this is a good method (along with using the Query Monitor that @sharedgird talked about.
 
Everyone here has good tips. I'm a behind the scenes type of guy and personally, if I had ssh access to the server, I'd be watching the queries as the page is loaded and see which one hangs. As @bigredseo said, optimizing and cleaning up the database can be huge. Database indexes make a world of difference as well.
 
bigredseo said:
As far as the mobile end of things, the "Today's Storystream" is loading first, then the "Featured" loads, but then the "Featured" takes the primary spot on mobile. So it's loading in the wrong order if you want the Featured to be first, and that's going to delay the display.
Click to expand...
Thank you, we are looking into prioritizing the display order. It definitely needs to be:
1. Featured column
2. Sidebar
3. Storystream

bigredseo said:
The page that loads doesn't have any YouTube videos, yet you're loading scripts to show videos (unused scripts). This may need to be removed if you're not planning on YouTube videos in the main feed.
Click to expand...
Good catch. I do indeed plan on having YouTube videos in the story feed. We've built a few types of posts, one of which is design to display finds from across a social media landscape.

bigredseo said:
Also, completely unrelated to speed, but the /news is being blocked for search engines. In the "meta robots" section, it's defined as "noindex, nofollow". That'll need ot be changed if you want to show on search engines.
Click to expand...
And here I've been searching Google daily to see if we got indexed yet...) Can't believe this happened and it was corrected this morning. I also went to submit the URL to be indexed and have already noticed the presence of Google Bot doing its thing. Maybe it's actually a good thing that it was protected from being crawled. With the older load time Google would have been incredibly unimpressed. Myth or not, but I wasn't in the mood to see the news site penalized with poor ranking.

bigredseo said:
A way to get more details on just what's slowing the page is to add in console commands on various sections.

In the code, you can add the following before a section:
console.time("Request")
Then add the following after:
console.time("complete")

You could do this on anything from database request sections, page display, columns, and specific content. It will narrow down exactly where all the time is spent on the page. It's a lot of detailed work, but if you're going hard-core on reducing speed even further, this is a good method (along with using the Query Monitor that @sharedgird talked about.
Click to expand...
Interesting. I am saving this for later reference.
 
Artashes said:
Good catch. I do indeed plan on having YouTube videos in the story feed. We've built a few types of posts, one of which is design to display finds from across a social media landscape.
Click to expand...
Since YouTube isn't on every post, and likely may not even be in a normal feed, instead of loading it in the background, you can load it only for the individual posts itself.

If someone wants to watch the video, they'd have to click the post, then watch the video. So the video in the Storyfeed would be more of an image than the actual video.

This does two things however;
  1. It generates a user engagement click, and a second page loading (both good things)
  2. It frustrates a user as they now need to click to watch a video (bad thing)
Its one of those things that you really need to do some A/B testing and see if the juice is worth the squeeze.
 
I am relieved to say that we now know what is causing the initial slow response time (TTFB). I am going to be making a detailed post about it in the next day or so. Daniel from @SharedGrid has been instrumental in this investigation. It's really fascinating stuff.
 
Cedric said:
Is it cached, like through Cloudflare ?
Click to expand...
If you did cache it through CloudFlare, you would want to separate it from the forum in my humble opinion.

That being said, WordPress caching could be good if the server side is what’s slow and not the client side.
 
You must log in or register to reply here.

Supporters

Back
Top