Initial Server Response Time on VPS is Slow

Edward_Mc

Joined
Feb 9, 2021
Messages
2
Likes
0
Degree
0
Hi All,

I recently bought a fully managed VPS from Heart Internet for an e-commerce client of mine.

He was on a shared server and the page speed insights were showing poor server response times and etc.

I have been through and fixed most of the outlying issues and I'm still left with "reduce initial server response time".

The whole point of buying a VPS was to get rid of the reduce response time warning.

When I have used a VPS in the past it has always been quick enough to not have the warning.

I am just wondering if anyone from the UK has experience with heart VPS servers or cam make me a recommendation.

Thanks,
 
Have you done things like pre-fetching and pre-loading resources so you don't have to wait on the browser to parse the source code and find the reference to it?

Have you implemented server-side caching so that the server doesn't have to compile the page from PHP requests to the MySQL database?

These are some of the things the server has to do once it receives a request before it can respond. The more efficient you make the time period between request and response, the faster the response will be. Even if you can throw more RAM and CPU at it, you'll always benefit from optimizing for the response.
 
Open a ticket with your host and see what they can do. If they keep on failing, talk to a new host and port the site there during the 1 week free trial. Then compare.
But, like Ryuzaki said, sounds like you purchased a cheap VPS with an old CPU.
 
Ryuzaki said:
Have you implemented server-side caching so that the server doesn't have to compile the page from PHP requests to the MySQL database?
Click to expand...
Yes I am using NGINX

Ryuzaki said:
Have you done things like pre-fetching and pre-loading resources so you don't have to wait on the browser to parse the source code and find the reference to it?
Click to expand...
I use Autotomize to manage scripts. I'm not sure I know how to do that much further on WP?

BakerStreet said:
But, like Ryuzaki said, sounds like you purchased a cheap VPS with an old CPU.
Click to expand...
I am wondering now if it is a poor quality VPS. There are minor improvements it is asking me for in page speed insights but I think I may be a bit out of my depth and it's only minor anyway. Sometimes the response time warning is there and sometimes it is not. When it's not there I get a good score. I like the idea of getting a trial first I maybe should have done that already.
 
This is how you test what's going on with your server.

1. Do a simple html page with hello world text:

Code: 
<!DOCTYPE html>
<html>
    <head>
        <title>Hello World</title>
    </head>
    <body>
        <p>This is an example of a simple HTML page with one paragraph.</p>
    </body>
</html>

Upload that page to your web server. Then go to pingdom and do a speed test on that page. Results:

0sBLusO.png

This show your potential maximum speed. Basically bandwidth server speed since there is very little to process. If you don't like the numbers you see here than you need a new server or hosting provider, because this is the bare minimum.

2. Now do a php-info page and upload it to your server:

Code: 
<?php

// Show all information, defaults to INFO_ALL
phpinfo();

// Show just the module information.
// phpinfo(8) yields identical results.
//phpinfo(INFO_MODULES);

?>

Results:
orT0r3C.png

Now you are seeing simple php rendering speed with data. PHP adds about 77 milliseconds to processing time. Now if you see a significant increase then it's PHP or some other software on your server causing a problem (could be a php plugin like php-mysql). Or simply could be an old version of PHP installed.

Here are some PHP benchmark tests:

PHP version​
Math​
String Manipulation​
Loops​
If / Else​
Total Time (seconds)​
8.3.0​
4.26598​
4.63107​
5.20907​
3.67280​
17.77891​
8.2.13​
4.29743​
4.82344​
4.79557​
3.60123​
17.51766​
8.1.26​
4.21514​
4.81550​
4.52323​
3.65630​
17.21017​
8.0.30​
4.35843​
5.07213​
4.48544​
3.57194​
17.48794​
7.4.33​
4.32484​
4.70973​
4.60100​
4.30911​
17.94468​
7.3.33​
3.44459​
4.75653​
6.61767​
2.19026​
17.00906​
7.2.34​
3.89996​
5.47336​
6.80690​
2.18567​
18.36589​
7.1.33​
3.92004​
5.99386​
7.55206​
2.51769​
19.98365​
7.0.33​
3.85731​
6.33998​
7.65740​
4.72646​
22.58115​
5.6.40​
17.26297​
16.07731​
25.64633​
9.65144​
68.63805​
5.5.38​
17.78154​
16.47247​
33.89310​
9.78380​
77.93091​
5.4.45​
18.72910​
16.78053​
24.96076​
8.97137​
69.44176​

Source: PHP Benchmarks

(Lower numbers are better)

Now obviously with every new PHP it gets faster and faster. However I will note PHP 7.3.33 was some sort of super anomaly - it was doing numbers newer versions of PHP can barely get to.

So if you find yourself on an older PHP upgrade the php and redo the speed test. Obviously you can see a clear jump from PHP 5x to PHP 7x and then to PHP 8x. After you got PHP settled goto the next step.

3. Now goto a page that your CMS is rendering and look at that, I'll do my homepage:

Nup9RCJ.png

That added an additional 490 milliseconds to rendering. If I want to improve that then I need to drill down and figure it out from there.

Now the homepage is usually the most intense so you should try other pages alongside to see what's really going on with your CMS.

If you are using WordPress or other related CMS you can start by turning off ALL plugins and doing the tests with no plugins, then enable one at a time and do the test to figure out exactly what plugin is causing your issues.

This way of investigating is from a first principles method of attack.


Break it down to the basics to figure out where your problem is. This is how I find the root of all problems when it comes to speed optimization - and with anything really.
 
You mentioned e-commerce and Autoptimize, so I assume you're using Woocommerce. That's usually the bottleneck.

Even then, it depends on which pages you're talking about. Dynamic WooCommerce pages can't be HTML-cached on the front end (/cart/, /checkout/, etc). Other non-woo pages can. There are other forms of caching though.

So the cart and checkout pages are going to be the slowest in a WooComerce site and there is only so much you can do on the frontend or wp admin about it beyond reducing plugins (experiment on a staging server by removing or replacing all non-essential plugins, converting them to functions.php hooks in your theme where possible, etc).

Hosting infrastructure: In my experience, Rocket.net tends to be the fastest out of the box for non-HTML catchable pages (i.e. WooCommerce checkout endpoints). I've compared response times in CloudWays / DO vs Rocket.net and others and it's significantly faster. They have a well-tuned CloudFlare enterprise and other caching schemes that benefit dynamic pages.

If you're not going to be on rocket.net, then I would look for alternatives like going headless (usually the least cost-effective option given the overhead converting it), migrating to Shopify, or experimenting with other layers of cashing like Varnish, Memcache, Redis, Relay, etc.
 
Did you implement CDN on your site?

My recommendation if you're building from scratch:

  • Select server location nearest your target visitor. If you're targeting US visitors, choose server location to US.
  • Use Nginx and PHP-FPM, then tune both for max performance.
  • Optimize your MariaDB/MySQL server.
  • Implement CDN for your site.
  • Implement memory caching like Redis or Memcached. Be sure to not stale cache too long for this.
 
n1x0 said:
Did you implement CDN on your site?

My recommendation if you're building from scratch:

  • Select server location nearest your target visitor. If you're targeting US visitors, choose server location to US.
  • Use Nginx and PHP-FPM, then tune both for max performance.
  • Optimize your MariaDB/MySQL server.
  • Implement CDN for your site.
  • Implement memory caching like Redis or Memcached. Be sure to not stale cache too long for this.
Click to expand...
Good list, yet the priorities should be different:
- Test how your VPS behaves under load (CPU load in top, memory utilization, and I/O load)
- Implement CDN to reduce the load, test again
- implement memory caching, if you have spare memory on the server
 
You must log in or register to reply here.
Back