AJ @ WpFASTER.org

Sorry my friend, but I am 99%(ish) certain that what you’ve got is a misconfiguration of the site’s server. Misconfigured either in itself or misconfigured relative to its compatibility with your exact W3TC settings/permissions.

To eliminate all doubt, completely uninstall W3TC (you can always re-install it, if you like, once the server is squared away).

A W3TC uninstall How-to, straight from the horse’s mouth, here.

Let me know how it goes. My curiosity is piqued (in case you didn’t notice lol).

AJ

To make sure I’m clear: is Browser Caching and GZIP currently enabled in W3TC or no?

Now, change your Page Caching method from Disk: Enhanced to Disk: Basic and again empty all caches, and re-check the site in ‘Private Mode’ in your browser of choice….

cf. Performance –> General Settings –> Page Cache –> Page cache method: –> Disk: Basic (from the drop down menu).

I don’t have a HTACCESS file. We are on a Windows server.

Oops, so you said. My apologies.

I have now done this and the site is not loading at all. I’ve had to disable the plugin and the site is running painfully slow for anyone who accesses it.

If the major problem (super-slow load) is still extant after disabling and/or completely (and properly) uninstalling W3TC, the culprit would almost certainly be a server misconfiguration. As an aside, the site is loading for me, albeit very slowly.

If you’re game, reactivate W3TC and untick both Database cache and Object Cache, empty all caches, and re-check the site in ‘Private Mode’ in your browser of choice….

Browser cache and Gzip caching were both ticked … I’ve tried enabling [GZIP] on our IIS server, but this hasn’t changed anything.

Take a look at your .htaccess file and make sure that you’ve not ‘doubled up’ on anything. In other words, W3TC automatically alters .htaccess (so long as permissions are correctly set) according to what is and is not ticked in the plugin’s UI (the dashboard); if you’ve gotten into .htaccess manually and altered something, there may be vestiges causing a conflict. This could — potentially — explain a lot, actually.

I unchecked the CDN option.

Did you clear all caches after doing so? (I’m still seeing “Content Delivery Network via N/A” at the bottom of the site’s source.) If not, do so and see if anything improves.

It states that Gzip is working on cached pages

“It” being the W3TC plugin?

Is there any way in which you can elaborate on this?

Let’s stitch up the hemorrhage before curing the headache. ??

AJ

Hi mrkidd1985,

W3TC does appear to be serving cached pages, so I don’t think that is the problem. What I do see, however, is that the site’s pages (depending on how one tests them) are generally 4+MB(!). You have to get that size down.

Aside from that:
1.) Browser caching does not appear to be enabled (for, at the very least, media and other files). To enable Browser Cache via W3TC: Performance –> General Settings –> Browser Cache –> tick “Enable”.
2.) GZIP compression is not enabled. To enable via W3TC: Performance –> Browser Cache –> General –> tick “Enable HTTP (gzip) compression”. This may or may not get enabled all by itself when you enable browser caching.
3.) At the bottom of the site’s source code (any page), you’ll see “Content Delivery Network via N/A”. I have never actually seen this before, but it leads me to believe either, A.) this box is ticked in Performance –> General Settings –> CDN without a CDN actually having been set up; or, B.) you’re the new owner of an as-of-yet unheard of W3TC gremlin. In any event, however, it is possible that this is somehow contributing to slow rendering from page-to-page (i.e. when navigating from one page to the next) insofar as something is waiting for something to serve the site’s assets. Troubleshooting: go to Performance –> General Settings –> CDN and make sure its not ticked; or, review your CDN’s setup, if you are, in fact, attempting to use a CDN, as it’s not working.

Try those, see what happens. To be frank, though, that’s really just the beginning as the site is for all intents and purposes entirely unoptimized for performance.

Best,
AJ

Hi xprt007,

You can exempt specific pages from the cache via: Performance –> Page Cache –> Advanced –> Never cache the following pages: (enter the pages you don’t want cached).

As far as all that code at the bottom of your source, you’ve got debugging on. To disable: Performance –> General Settings –> Debug –> Debug Mode: (untick whatever is ticked).

Best,
AJ

Not sure if you’re into coding AJ

I’m no Frank Goossens ?? but I see where you’re going with the above example. It’s definitely something I’ll pass along to the team.

All of my suggestions are, however, predicated on the idea of being able to accomplish a more refined in-lining approach via the GUI, even if only for the convenience value that offers to everyone, from advanced coders to those launching their very first WordPress site… That said, I do realize there’s only so much time available to evolving a free plugin, regardless of the soundness of the argument that necessarily follows from the above premise.

Ultimately, I suppose my concern is that AO’s option to inline and defer one’s CSS will go unused, when everyone should at least be trying to use it.

Best,
AJ

…One other quick thing:

Lastly, if you’re adamant about using the inline & defer option:

I would simply load Google Page Speed Insights and get a list of the stylesheets that are loading on the page you’re having issues with — without Autoptimize; uncheck everything css-related.
Take that list, and just paste the stylesheets (just the .css part, not the http / wp-content / plugins, etc. part.) … one on a line should do, or at least separate ’em by commas.
Tick the Autoptimize CSS Code box. Paste the .css stylesheets in the “exclude” box all at once. Your page should load normally now, as if Autoptimize wasn’t messing with your css.
From there, simply eliminate them one-by-one until you find the culprit that’s messing up your front-end. Once you find the culprit, well, that’s what you exclude from deferring. Just save/clear cache and refresh the page you’re having issues with. This may sound tedious, but I bet it takes you less than 10 minutes.

^ This indicates a misapprehension of how the Inline and Defer CSS option works (and in-lining CSS more generally).

The CSS critical to rendering ‘above-the-fold’ content is comprised of aspects from most — usually all — of a sites stylesheets. It makes no sense to speak of excluding stylehseets, as only critical CSS (again, taking from a site’s total CSS) is in-lined in the first place.

The problem I am addressing (cf. first post) is that the CSS critical to one page usually differs on others. Therefore, a universally applied (site-wide) block of critical CSS, however optimal for the page(s) for which it is, is sub- or nonoptimal for others.

AJ

@ RebellionNT1,

You’re pretty much good to go, but there are a couple of easy things (they won’t improve your score on Google’s Page Speed Insights but will make the site even faster):
1.) You can Sprite those background images.
2.) I didn’t look at every page, but it appears your site is entirely static or nearly so. So, were you to sign up for CloudFlare, you could set up a Page Rule for the site and make use of the “Cache Everything” directive therein, thereby making your site as fast as if it were on a VPS or dedicated server.

Best,
AJ

Hi WebPrezence,

I’m not looking for an answer to anything, per se, but making suggestions for potential improvements to the new Inline and Defer CSS option within AO.

While I’m not interested in a debate on the merits of optimizing a site’s critical rendering path (it would be like debating whether or not gasoline is ‘good’ for a car), I’m compelled to address a few things you’ve mentioned for the benefit of a learning audience that might read this thread.

I’m not sure what is meant by inlining all CSS “doing the best job for [you]”, but as far as inlining all CSS goes, it is literally never the best option for any website except those with very, very small amounts of total CSS. The vast majority of WordPress sites have large, complex CSS.

When one in-lines large amounts of CSS into their site’s HTML (your website’s homepage, for example, linked to via your forum username, its HTML weighing-in at a massive 82.2kB), the browser cannot cache that… it has to deal with that on every page load as someone navigates throughout a website. Obviously, this slows down not only the first, initial rendering of a page when someone first lands on such a site, but slows down moving from one page of that site to the other; and, in effect, kills the benefits of things such as page caching.

In-lining only the CSS required to render ‘above-the-fold’ content (and deferring the rest) saves a round trip to the server and allows for much faster rendering of a page given that the rendering is not blocked by a CSS file. That said, combining a site’s CSS into a single, cachable file (thereby reducing HTTP requests) nonetheless constitutes the more optimized scenario — and does so on orders of magnitude — than does in-lining massive amounts of CSS, for the reasons already mentioned and then some.

Which is why Autoptimize’s Inline and Defer CSS option is so exciting, as AO is (to the best of my knowledge) the only plugin in existence that enables one to truly optimize the rendering path. The feature is not problem-free, however, and will go through, I imagine, several incarnations — the next one I hope to shape. Ergo this thread.

Best,
AJ

My apologies, RebellionNT1, but I don’t understand the question.

Well, because I do not think you’ll be able to optimize more

You can, though. If you inline critical, above-the-fold CSS and defer the rest (i.e. make use of Autoptimize’s Inline and Defer CSS option), this will be — by definition — a more optimized scenario.

In ping doom hosting guys told me I had to make a choice of amsterdan and gives me a punctuation of 99/100 and 937ms load time.

If your site’s users are all in the general vicinity of Amsterdam (it appears that this site is for a local business in Asturias?), then you’re fine. If and when, however, your business site caters to the larger, Spanish-speaking world or begins to do European-wide (or global) business, you’ll want to make use of a CDN so the site is fast everywhere. (As an aside: CloudFlare would still benefit your site in numerous ways. Further, for Spanish visitors, CloudFlare would serve your site from Madrid: The closer the site’s user is to an edge server, the faster your site will be. I.e. a Spanish user of your site, in Spain, would experience a faster page load than that same Spanish visitor being served your website from Amsterdam.)

The worst thing I have is google page speed that the issue of punctuation mobile only have 72 and version desktop 89 which is not bad, what I would like would be to improve the punctuation for mobile

Which is exactly why you might try to inline the site’s CSS with Autoptimize, as in-lining critical, above the fold CSS shows its greatest benefits for high latency devices such as mobiles. The Google Page Speed warning you are getting about render blocking CSS is there primarily to let you know that you can improve the speed (and therefore user experience) of your mobile site by optimizing your CSS:

From Google:

Optimize CSS Delivery:

This rule triggers when PageSpeed Insights detects that a page includes render blocking external stylesheets, which delay the time to first render.

Overview:
Before the browser can render content it must process all the style and layout information for the current page. As a result, the browser will block rendering until external stylesheets are downloaded and processed, which may require multiple roundtrips and delay the time to first render. See render-tree construction, layout, and paint to learn more about the critical rendering path, and render blocking CSS for tips on how to unblock rendering and improve CSS delivery.

Recommendations:
If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page. Keep in mind if the CSS file is large, completely inlining the CSS may cause PageSpeed Insights to warn that the above-the-fold portion of your page is too large via Prioritize Visible Content. In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.

^ Ergo, Autoptimize.

Best,
AJ

Hi RebellionNT1,

I installed the Autoptimize and have disabled minify W3 Total Cache, the javascript files is not able to combine them all into one, and pulled out the lowest score in google page speed, I think it’s better to have the minify of w3 Total cache or not the Autoptimize is set,

If you were happy with what W3TC was doing for your JavaScript, you should continue to use W3TC for that. You do, however, need to make sure that you are only using one plugin for each type of minification or you’re website will ‘break’.

For example, if you’re using W3TC for your JavaScript, make sure that you’re not also attempting to minify your JavaScript with Autoptimize; if you’re using Autoptimize to minify your CSS, make sure that CSS minification is disabled in W3TC. Etc.

In short, It is not an all-one-plugin-or-the-other-for-all-minification-purposes solution I am proposing, but a ‘mix-and-match’ sort of thing, pulling the best features out of each to achieve your goal.

As I understood it, the primary issue you were having had to do with the render blocking, combined CSS file created by W3TC (as indicated by Google Page Speed Insights). W3TC cannot help you with Google’s recommendation to fix this render blocking CSS file. The first, best plugin solution is Autoptimize and its Inline and Defer CSS option (you will see this option if you click on “Show Advanced Features” in the Autoptimize dashboard). Follow the above linked how-to guide for this feature and you’ll more than likely have solved the problem.

there is some kind of tutorial to configure correctly Autoptimize with the w3 Total cache?

Not that I am aware of; if there were, it is unlikely it would do you any good: There are simply too many variables and permutations since every website is different. Further, the online set up guides for just W3TC, are actually people illustrating what worked for their site and set-up, not what constitutes a fully optimized scenario for yours since your site and set-up is unique (more info here).

On the issue of burden of my server does not understand why it takes so long to answer,? is there any way to know what is fault ?

Are you on shared hosting?

Cloudflare improves the loading time of the web ?

Oh yes. ??

I have fear because you have to change the dns domain and did not like it much, I’m afraid that the burden of web malfunction or slow down,

We add CloudFlare to our own client’s sites all day every day and it always goes smoothly. I am confident that once you sign up for CloudFlare, you’ll be happy that you did.

Best,
AJ

Hi Josh,

Rocket Loader would be nice as it really speeds up the page load time, but it breaks my Jetpack sharing buttons and it creates the caching problem with ClickDesk.

Sounds like dependency issues arising from inline scripts, especially if you were formerly (and successfully) asyncing your .JS with W3TC… Were you able to combine all .JS with Autoptimize, or did you have to exclude certain files to get it to work?

…Further, Rocket Loader (as an asynchronous JavaScript loader/virtual browser) has no technical connection to caching… none that I can think of off the top of my head, anyway. This does indeed sound like an issue with W3TC config/permissions and/or dependency issue(s) arising from script placement. Is there still no way to provide a URL to have a look at?

I really like CloudFlare’s Rocket Loader but it breaks my scripts that are appearing on every page. If possible, it would be nice if CloudFlare could add the option to exclude certain files.

I’ve been at them about this for longer than I can now remember. For a reason I know not what, they’re not interested in refining Rocket Loader in this manner. As I ask all people that ultimately come to the exact same, obvious conclusion/solution you have, please do let them know what you think via CloudFlare support. If enough people make the effort to complain about how ridiculous it is to not be able to exclude scripts right within the CloudFlare dashboard, they have to get on the ball with an appropriate change.

Best,
AJ