Search Results for 'cache'

Well, the author page works for me and I run YOAST SEO ….

You should double check your settings in YOAST, resave your “permalinks” from the main WP settings, clear all your cache.

Issues with YOAST…

1) have had some issues with the “force transport”
2) have had some issues with “remove stop words” from slugs

Maybe that helps, maybe not.

Fixed O.O

I should really hire you @Steven for my website 😉 haha

Plugin Results (after recent changes etc):

WordPress Plugin Profile Report
===========================================
Report date: Oct 1, 2014
Theme name: Newspaper
Pages browsed: 30
Avg. load time: 1.1474 sec
Number of plugins: 23
Plugin impact: 72.88% of load time
Avg. plugin time: 0.8362 sec
Avg. core time: 0.1939 sec
Avg. theme time: 0.1235 sec
Avg. mem usage: 80.81 MB
Avg. ticks: 42,507
Avg. db queries : 147.77
Margin of error : -0.0062 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0014 sec - 0.17%
Adminimize - 0.0240 sec - 2.87%
Akismet - 0.0042 sec - 0.51%
All In One Wp Security And Firewall - 0.0156 sec - 1.87%
Append Link On Copy - 0.0007 sec - 0.09%
Easy Social Share Buttons for WordPress - 0.2501 sec - 29.90%
EWWW Image Optimizer - 0.0474 sec - 5.67%
Jetpack by WordPress.com - 0.0720 sec - 8.62%
WPBakery Visual Composer - 0.0610 sec - 7.30%
myCRED - 0.0419 sec - 5.01%
Nextcellent Gallery Nextgen Legacy - 0.0172 sec - 2.05%
Recent Posts Widget Extended - 0.0092 sec - 1.11%
Revolution Slider - 0.0257 sec - 3.07%
Speed Booster Pack - 0.0254 sec - 3.04%
tagDiv speed booster - 0.0010 sec - 0.12%
TinyMCE Advanced - 0.0003 sec - 0.04%
W3 Total Cache - 0.0129 sec - 1.54%
WooCommerce - 0.0745 sec - 8.91%
Wordpress Seo - 0.1073 sec - 12.83%
WP-Optimize - 0.0053 sec - 0.63%
WP-Polls - 0.0014 sec - 0.16%
WP User Avatar - 0.0199 sec - 2.38%
Xml Sitemap Feed - 0.0177 sec - 2.12%

Woo! Getting so much better 🙂

New report (looking better, thanks!):

WordPress Plugin Profile Report
===========================================
Report date: Oct 1, 2014
Theme name: Newspaper
Pages browsed: 31
Avg. load time: 2.2055 sec
Number of plugins: 25
Plugin impact: 69.68% of load time
Avg. plugin time: 1.5368 sec
Avg. core time: 0.3922 sec
Avg. theme time: 0.2436 sec
Avg. mem usage: 90.45 MB
Avg. ticks: 40,758
Avg. db queries : 143.68
Margin of error : 0.0329 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) – 0.0029 sec – 0.19%
Adminimize – 0.0479 sec – 3.11%
Akismet – 0.0115 sec – 0.75%
Append Link On Copy – 0.0028 sec – 0.18%
Easy Social Share Buttons for WordPress – 0.0929 sec – 6.05%
EWWW Image Optimizer – 0.0638 sec – 4.15%
Jetpack by WordPress.com – 0.1521 sec – 9.89%
JM Twitter Cards – 0.0111 sec – 0.72%
WPBakery Visual Composer – 0.1214 sec – 7.90%
myCRED – 0.0923 sec – 6.00%
Nextcellent Gallery Nextgen Legacy – 0.0423 sec – 2.75%
Query Strings Remover – 0.0049 sec – 0.32%
Recent Posts Widget Extended – 0.0202 sec – 1.32%
Revolution Slider – 0.0685 sec – 4.46%
Social Networks Auto Poster Facebook Twitter G – 0.1419 sec – 9.24%
tagDiv speed booster – 0.0021 sec – 0.14%
TinyMCE Advanced – 0.0013 sec – 0.09%
W3 Total Cache – 0.0278 sec – 1.81%
WooCommerce – 0.1576 sec – 10.26%
Wordfence Security – 0.0583 sec – 3.79%
Wordpress Seo – 0.3268 sec – 21.26%
WP-Optimize – 0.0126 sec – 0.82%
WP-Polls – 0.0030 sec – 0.20%
WP User Avatar – 0.0383 sec – 2.49%
Xml Sitemap Feed – 0.0325 sec – 2.11%

Ook, i don’t know, maybe it’s cache or something…
I use this, right?

@media (max-width: 767px){
.header-logo-wrap .header-logo-wrap img {
display: inline !important ;
}
.td-header-bg .header-logo-wrap {
width: 295px !important;
}
.entry-crumbs {
display: block;
}
.post header h1 {
margin-top: 17px !important;
}
}

@media (min-width: 768px) and (max-width: 1024px) {
.td-header-bg .header-logo-wrap {
width: 295px !important;
}
}

That’s what i thought, because i couldn’t find any topics relating to this.

This is my full plugin report and speeds:

WordPress Plugin Profile Report
===========================================
Report date: Sep 30, 2014
Theme name: Newspaper
Pages browsed: 47
Avg. load time: 3.1552 sec
Number of plugins: 28
Plugin impact: 85.63% of load time
Avg. plugin time: 2.7019 sec
Avg. core time: 0.2760 sec
Avg. theme time: 0.1465 sec
Avg. mem usage: 95.55 MB
Avg. ticks: 41,654
Avg. db queries : 137.30
Margin of error : 0.0308 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) – 0.0022 sec – 0.08%
Adminimize – 0.0481 sec – 1.78%
Akismet – 0.0095 sec – 0.35%
Append Link On Copy – 0.0012 sec – 0.04%
Compress Png For Wp – 0.0007 sec – 0.03%
Easy Social Share Buttons for WordPress – 0.0592 sec – 2.19%
EWWW Image Optimizer – 0.0816 sec – 3.02%
Hide My Wp – 0.4908 sec – 18.17%
Jetpack by WordPress.com – 1.2664 sec – 46.87%
JM Twitter Cards – 0.0134 sec – 0.49%
WPBakery Visual Composer – 0.0815 sec – 3.02%
myCRED – 0.0708 sec – 2.62%
Nextcellent Gallery Nextgen Legacy – 0.0293 sec – 1.08%
Query Strings Remover – 0.0005 sec – 0.02%
Recent Posts Widget Extended – 0.0074 sec – 0.27%
Revolution Slider – 0.0537 sec – 1.99%
Social Networks Auto Poster Facebook Twitter G – 0.0945 sec – 3.50%
tagDiv speed booster – 0.0018 sec – 0.07%
TinyMCE Advanced – 0.0033 sec – 0.12%
User Switching – 0.0073 sec – 0.27%
W3 Total Cache – 0.0433 sec – 1.60%
WooCommerce – 0.1074 sec – 3.97%
Wordfence Security – 0.0455 sec – 1.68%
Wordpress Seo – 0.1308 sec – 4.84%
WP-Optimize – 0.0107 sec – 0.40%
WP-Polls – 0.0014 sec – 0.05%
WP User Avatar – 0.0216 sec – 0.80%
Xml Sitemap Feed – 0.0181 sec – 0.67%

Hello Lucian , I have all plugins disabled and cleared the cache and tried to create new buttons .

But for some reason , the buttons just do not work with me anymore . Pity .

Greetings

@christophersimmons
Hello! Thanks for your reply. The first the I checked was WT3C cache plugin if its causing that but the minification is off. I’ll try to do what you have suggested. Thank you!

Thanks. The problem turned out to be that I switched to WP Super Cache to see if its performance was any better than W3 Total Cache, but then I switched back. I checked my .htaccess file on a sneaking suspicion and sure enough, WP Super Cache hadn’t cleaned up its rules properly, which explains why none of the caches I was clearing did anything.

All good now. 🙂

Well, basically it is serving up an image at smaller size and so caches the “scaled” size as part of the “rewrite” images module.

Sometimes it doesn’t work if the optimized image would be larger in size than the original, which is funny since I usually optimize stuff very much in the extreme.

But:

ModPagespeedEnableFilters resize_images

This attempts to resize any image that is larger than the size called for by the width= and height= attributes on the tag or an inline style= attribute. The original image is replaced only if the image file is smaller after resizing. Image resizing is lossy by nature, regardless of image file format.

Note: It also strips color profiles and metadata even if strip_image_color_profile and strip_image_meta_data are disabled.

Note: If both resize_images and resize_rendered_image_dimensions are enabled then resize_rendered_image_dimensions takes precedence.

Partnered with:

ModPagespeedEnableFilters insert_image_dimensions

This flag inserts width= and height= attributes into tags that lack them and sets them to the image’s width and height. Note that this can cause image stretching or shrinking if CSS rules specify only one image dimension (see Risks below).

So, one of those things to play with for super advanced users, like removing width=500 height=375 and simply using style=”width:90%;height:auto” can do some interesting things.

Eventually this stuff will be built in to everything, since rewrites on the fly solve numerous responsive design issues.

AND: we just now got mod_spdy and mod_pagespeed working together!!!! WOOHOOOOO!!! Doom will ensue! (kidding)

This is actually one of the cool things about mod_pagespeed … if you have an image loading over and over at 80% size, it will cache the image at THAT SIZE and serve up the smaller image to people who keep requesting it vs loading the larger image and scaling it.

So let’s say an iPhone is requesting that 745 pixel wide image, with mod_pagespeed, it will know that the iPhone can only display a 640 px wide image and then serve it a new thumbnail?

That’s pretty cool if true. Thanks!

@tcdraper
the general reason themes don’t make multiple thumbnails for the sizes you’re talking about, is that when an iPad changes from portrait to landscape it’s not technically reloading the page, just refreshing the viewport and the cached stylesheet is applied; otherwise it would be *worse* for mobile since the images would need to actually be reloaded — ever carry an iPad across the room in unlock mode and have it flip back and forth from portrait to landscape; well, you’d be reloading the images in different sizes more than once.

So, one aspect of “responsive” design (good and bad), is that it’s better to load a 25kb image once than load the 25kb image once and the 12kb image together and switch those out on viewport. Better to load the 25kb image ONCE, then resize to fit the aspect you’re looking at when you look at it.

The other benefit of using the larger image is for retina/HD displays on a mobile device which have higher pixel count than desktop; so again, if you do the pixel math, a 700×500 image on a screen with double the pixel count, loaded half size, would still provide the same number of pixels when shown half size — without having to load alternate retina/HD version of image or use “image stacks.”

This is actually one of the cool things about mod_pagespeed … if you have an image loading over and over at 80% size, it will cache the image at THAT SIZE and serve up the smaller image to people who keep requesting it vs loading the larger image and scaling it.

That was mostly anecdotal … but just some techie crap in case you were curious 🙂

@tcdraper
we’re running PHP Version5.4.22; apache, centos 6x, plesk/parallels, all the built in modern accelerators, apc/memcache, mod_pagespeed, and just last night got “mod_spdy” working on Plesk, which was fun since my data folk had never done it before and was team effort.

We’re right now (literally) working to connect mod_pagespeed to SPDY properly so we can have mod_pagespeed load and compress/cache images and other https elements when the pages are loaded 100% https.

Not using Amazon S3 CDN at moment as I can’t mentally deal with the sharding setup when all of us working on this project have never done this before and there is *NOT* a simple “how to” book on this!

I think we were getting something like 330 msec or something, and Google thinks initial response should be under 200-300. (Sigh.) We have a 300kb static page with 10 elements loading dynamically via server side includes in 1.3 seconds total, and pagespeed of 96 without CDN or caching application, and that’s not good enough? BAH!

So, far the https optimizations built into server seem to work fine for desktop, lose a point, page load goes from 1.4 to 1.5 seconds total. So, will be testing that with mod_spdy active, and then with mod_spdy PLUS mod_pagespeed to see if we can enhance the times overall.

ANyway… kind of rambling there. No real advice for you. We have a dedicated multicore XEON server, 32GB RAM, with its own gigabit switch so we don’t have to deal with a lot of the shenanigans of VPS and shared hosting. But, $650/mo. isn’t exactly cheap, either.

That wasn’t a very good answer, was it ? 🙂

• This reply was modified 11 years by simchris.

Same over here, the dropdown menu is messed up after updating to 4.4

example: http://goo.gl/F1fyL

This is what i’ve tried so far:

– Flush all cache (no improvement)
– Disable all plugins (no improvement)
– Deactivating Cloudflare (no improvement)
– Rolling back to 4.3 (dropdown menu looked fine again)
– Installed 4.4 (dropdown messed up)

I will follow this topic for updates.

Cheers!

• This reply was modified 11 years by JBH.