Summary: Likely good for you to hire someone to audit your code + fix all the following items + help you escape your custom code mire.
[ … soap box mode on … ]
You probably won’t like this. Just my opinion.
First I’ve been running high speed, private site hosting since 1994 + I’ve seen it all.
I personally dislike custom code. Oh developers will always say, you don’t want WordPress, it’s way better to write some fast custom code to run your site.
I tell my clients anytime they hear this out of a developer’s mouth, fire the developers, instantly.
[ … soap box mode off … ]
Now that I have that out of my system…
- You’re running custom code, there’s really no telling what quality code you have.
Writing optimal SQL code is easy for WordPress (or other CMSes), where 1000s of developers constantly comb the code + find problems + fix them.
In your case, best you can do is log slow queries + missing index queries + fix every one of them.
mysqltuner is your friend. Use it to clear all problems.
- TTFB is easy to understand.
The primary influencers are your runtime environment + code choices.
Code choices, I’ve covered. You’re using custom code, so you’re at the mercy of your coder(s).
- Runtime environment means your Stack + other sites running on your machine.
Your site seems to be the only site on your machine, which means you’re likely running on a dedicated server, which is good. No other sites to drain performance.
Your hosting with Gyron Internet Ltd, which might mean you’re running in some VPS slice or VM, both of which will be highly influenced by other sites running on same hardware.
Now for you Stack.
You’re running NGINX. Ugh… I stopped using NGINX years ago… Nothing but problems…
I only use Apache + FPM PHP for all my hosting clients.
Every speed test I do shows 30%+ faster than NGINX. Likely because I run a highly optimized runtime setup.
So I’d suggest you test switching to Apache + retesting your speed.
- Erratic TTFB usually means swapping (to little memory) or disk i/o thrash (to much writing), especially where disk i/o channel is shared with other machines/sites, as with large disk arrays.
This can also occur when NGINX repeatedly crashes + restarts for every page request.
The only way you can tell if this is occurring, is referring to your logs.
- Try also enabling deep FPM logging, which shows each .php file accessed + the CPU time required to run each .php file.
Find the erratic .php files, ones with wildly different CPU times which are called with the same arguments. These are best candidates to start fixing.
- Fix your HTTP + HTTPS redirects, as currently you have a site wide duplicate content penalty, because both http + https both return 200 + content. Google use to allow this + no longer does.
I setup all my client’s site to do the following, so there’s never a chance of a duplicate content penalty.
https://foo.com - returns 200 + content.
https://www.food.com → 301 to https://foo.com
http://food.com → 301 to https://foo.com
http://www.food.com → 301 to https://foo.com
- Your site runs HTTP1.1, so change to HTTP2 for best performance.
This won’t effect TTFB. It will dramatically effect all other content requests.
- Fix your SSL config.
https://www.ssllabs.com/ssltest/analyze.html?d=www.beggshoes.com reports a low score, mainly because your issuer chains are incorrect.
Chrome + Firefox have both been considering lowering the hammer on broken SSL configs like this.
At some point, your site will likely be flagged as suspicious… because… well… it is.
Badly broken SSL configs mean either the config is really broken or something nefarious is in between the site + browser.