Is website Nirvana possible? TTFB and Rendering issues

Web Performance Discuss Test Results
1

Hi folks, I’m hoping you can help…
I work for a small shoe retail company and have been plugging away at trying to make the website as slick as possible. Our website is www.beggshoes.com The company we work with have done great work in getting us to where we are now but I have a few things that I just don’t understand…

  1. On most metrics we seem to be doing ok but the one that bothers me the most is that we score a D for TTFB. Now I know that there are many things that can influence TTFB, our server does seem to throw out erratic “Wait” times when I check on Pingdom and GT Metrix but our web development guys don’t seem to be able to do anything to stabilise the wait times and/or lower the TTFB.

  2. Another thing that I am battling with is our users have to wait a fair bit of time and then POOF the whole page renders . I would rather they elements loading as early as possible so that they don’t wait for 4 seconds with a blanks screen and think that the site is down and just leave.

Before I accept that nothing more can be done, I thought I would just throw it out to the people who know stuff. Am I seeking improvements where improvements can’t be had or is website nirvana still possible :slight_smile:

Thanks in advance

Craig

2

It’s definitely possible to get an A grade for an ecommerce website. Most of this is backend time. I’m not sure what type of CMS you are running so I can’t say what sort of TTFB time would be realisticaly possible on your website.

Here’s what I would recommend doing:

  • Switch to http2 so resources load in parallel

  • You may want to move to a more optimized server and ensure you are running the latest software PHP7, mysql (or whichever runs your database), and nginx. Your nginx version is 1.10.2 which was released a year ago so I’m assuming other software is also out of date.

HTTP2 will help with frontend optimization and will help to decrease that 4s paint delay. The way the carousel loads the brands is also blocking the page from rendering. As the browser is waiting for the .php file then all of the images for the brands before it renders the page. I would load this with the initial html content. There isn’t a reason to call the brands.html.php file on every page.

3

Thanks so much for your answer, the CMS we are running is proprietary coded (and a bit clunky I think). I just want to ensure that we do optimise what we can optimise. Thanks for picking up the carousel error, no idea why it was implemented as render blocking and also why it is running on every page.

I was ask our services providers about the server they are running (although they assure me it is as good as it gets) but I have no doubt improvements can be made. It just seems that I am the one having to do the homework to ensure the improvements are made.

Once again… thanks a million.

4

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…

  1. 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.

  1. 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).

  1. 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.

  1. 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.

  1. 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.

  1. 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

  1. 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.

  1. Fix your SSL config.

SSL Server Test: www.beggshoes.com (Powered by Qualys SSL Labs) 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.