Are you intentionally trying to give your posts “.html” on the end of their urls, perhaps in your htaccess file? If not, please post the contents of your htacess file so we can help you sort it out.
Or if you have a plugin handling this for you, you might try turning it off.
You named your subsites postc1.html? Or those are your postname URLs?
Thread Starter
ssbala
(@ssbala)
@ Bet Hannon, yes i added .html at the end of urls through permalink structure.
@ Ipstenu those are post name URLs.
Also my sub blogs having high response time over main blog, they are taking atleast 0.40 to 1060 seconds to respond. i uninstalled some plugins few days before since from that day my sitemap is not disappearing…
Thread Starter
ssbala
(@ssbala)
they are taking atleast 0.40 to 0.60 seconds to respond.
some times permalink format of 2 and 3 sites automatically changes to domain.com/blog/postc1.html and domain.com/blog/posts1.html.
I would think that anything that’s resetting THAT to a non-standard URL format like .html would be the issue with why your site is so slow.
What plugins are you running network wide?
Thread Starter
ssbala
(@ssbala)
today also i faced this issue, i am using following plugins
Anti-spam, Autoptimize,Ultimate Category Excluder, W3 Total Cache,WordPress SEO, WP-HTML-Compression and Add target=”_blank” to external links
Autoptimize would be my top pick.
Turn off that.
Regarding the performance-issue; if running Autoptimize, using a page caching plugin (or similar external solution) is highly recommended. If you don’t have page caching and if your pages have page-specific (or worse, request-specific) JS/ CSS in them, then Autoptimize won’t be able to draw from it’s own cache, leading to all aggregation & minification having to be done over and over again, which is (relatively) costly.
frank (ao’s developer)
He;s using W3TC already.
then Autoptimize won’t be able to draw from it’s own cache,
Wait… Autoptimize calls it’s own cache?
Almost 😉
1. when using a page cache, pages (i.e. HTML including links to AO’s cached aggregated & minified JS & CSS files) will be served from W3TC. In that case AO does not get called (except on first pageload) and there should be no performance impact (quite on the contrary). this should
2. when not using a page cache, AO will get triggered on every pageload, with the following substeps:
2.1. CSS & JS is extracted and aggregated
2.2. using a hash AO checks if it already has a cached file of that exact collection of CSS or JS
2.2.1. if no cached file is available, the CSS and/or JS are minified. this is the most CPU-intensive operation and the file is immediately cached
2.3. the link to the autoptimized css/ js is inserted in the HTML
2.4. the HTML is minified (no cache for that in AO).
So:
* if one is using a page caching mechanism, all is fine (although off course initial page load does trigger AO)
* without a page cache, the most important impact is when there’s page- or request-specific JS or CSS, which means AO can’t use already minified aggregated CSS and JS files from it’s own cache.
So for this support-thread specifically; if ssbala is using a page cache, then performance issue are not due to AO.
Hope that’s somewhat more clear then my previous shorthand-answer 😉
frank
Provided he configured it all properly 🙂 Fastest way to find out is to turn off the plugin and see if the problem stops.
