mikeotgaar

Agree your TTFB is poor.

I suspect the problem is your hosting server, however try seeing if there’s another reason before finding a new hosting service. The W3TC debug info (in page source) shows it takes 6.411 seconds to create cache files for first page served – which indicates a hosting server issue to me.

It’s the same as finding a faulty plugin.
Turn off (deactivate) each plugin one at a time, clear the site cache and test the site several times allowing some time between tests.

Jetpack is a heavy resource user and also uses a 3rd party server to load files. Poll & Quiz Tools by OpinionStage also uses a 3rd party server. 3rd party servers can slow down your site – if that server is slow or busy.
Akismet uses a 3rd party server to check for spam, but doesn’t do anything that can slow things down until a comment is posted.

From your source code it looks like you are using a CDN (NetDNA) to load some scripts. Sometimes using a CDN is slower than serving files directly.

Maybe you could try minifying the CSS and JS files – combining as many as possible into a single file. Usually you need to do this manually in W3TC, not using the automatic option, as sometimes you need to exclude some scripts to retain functionality.

In W3TC settings set expires header to at least 24hrs (86400 seconds)

Also enable cache preload – you’ll need a sitemap.xml file to work with the W3TC preload function

Other comments: The front page is image heavy which will slow down page load speed, but should not impact time to first byte.

Only thing to add to 12ax7 tip is delete the plugin folder using the site file manager (Cpanel etc) not WordPress plugin admin.

@garageflooringllc

I would turnoff the Yoast Sitemap function – or seeing as you paid them to “tune” your site tell them to do so, and at the same time disable the admin nag messages you will get from Yoast SEO when using another sitemap plugin!

It looks to me like you are using “WP Fastest Cache” for caching. This plugin preloads the HTML static page cache based on the links in your sitemap, and doesn’t work properly with multiple sitemaps.

Other caching plugins including W3TC and WP Super Cache also use the sitemap to preload the cache, and these also don’t work properly with multiple sitemaps

It’s very important to cache WordPress pages/Posts to get best Google page load speeds, and the best way is to preload the cached files instead of waiting for someone to view the page before generating a fresh cached version. I’m really surprised Yoast has not taken this into account with their plugin and their “SEO” guidlines.

It really makes no sense to use a sitemap_index.xml file and multiple sitemaps for a website with under 50 000 pages – there’s no need.

Cool!
Great plugin – one of the “Must Use” plugins

Try deleting the WordPress updates folder from site installation (site root) – it usually works for the annoying nag messages this plugin generates.

Nice…
Your fix also fixed the constant nag about another sitemap plugin too. I really wish Yoast will stop these nag messages or at least give us an option to turn them off permanently

We could be. Willing to buy if it’s good enough and works with WordPress SEO plugin etc. And must be responsive

Definitely
Just look for the WordPress SEO by Yoast box under the post/page editor – you’ll find all the fields you need to set titles, descriptions and a bunch of other useful stuff…

Try:
*@*.hammerwin.com in Deny list

I agree this constant nag message is annoying

You got it *****
Not a problem, these things happen…

@kpgraham
Here’s a transparent image to use
https://graphiclineweb.files.wordpress.com/2015/02/index.png
Any images you need tweaked – let me know

Suggestion: It may be an idea to change the way the image is called – data:image/png;base64string in /settings/settings.php to rather us a static image URL. Less likely to have the file flagged by security software or blocked by .htaccess security rules

@ipstenu
How about a way to turn it off for ALL users?

In other words, completely disable the feature…

Some users may need to do one more step:
Delete the existing Dropbox authentication after re-installing the plugin as described by Daniel, and re-authenticatee the Dropbox API

Worked for me.

Fixed ?? Great response especially at this time of the year

I guess the wick thing was some redundant code from a much earlier version?

(I didn’t mention a version of WP as I’m running several; 3.8.*, 3.9.*, 4.1 with better search.)