red.green.blue

Hi Daniele, thank you for offering to help. How do I PM my website address to you?

+1

I’m assuming @godaddy is the well known hosting company? If so, this is lack of support is harming their reputation. (If it’s not, @godaddy is harming the reputation of a large company – who have lawyers who should be told about this!)

Please see my thread ‘Not At All Useful for Assessing Visitor Experience…?‘ as I’m not even convinced that this plug-in is doing what people think it’s doing – and is therefore useless!

As an aside, reading elsewhere about the P3 Profiler, it seems that the results P3 generates is for the logged-in Admin users – not a non-logged-in visitor.

The results would be VERY different for a non-logged-in visitor.

I am currently of the opinion that using the P3 Profiler is of no value whatsoever. I will comment here if I change my mind.

I don’t care how much plug-ins slow down the site while I am working on it. I only care about how plug-ins affect my visitors. The P3 Profiler doesn’t appear to tell me anything about that.

Is WPMU DEV Support able to confirm that any sidebars generated by the Custom Sidebars plugin would be cached by the W3 Total Cache plug-in and, therefore, people who use that would see absolutely NO performance problem by using Custom Sidebars?

I’d like to +1 this thread.

Personally, I don’t care about any plug-in performance issues for ME when working on my site. What I care about is the impact for my visitors of plug-ins.

I’ve read this thread and am still unsure whether the suggestions will test the performance of my site’s plug-ins for those visitors who are not logged in as Admin. Would someone be kind enough to confirm that for me?

I too am seeing this issue. Are you able to confirm that the plugin definitely does NOT slow down page generation for visitors in the manner suggested by the P3 profiler?

Hi,

First, this plug-in is soooooooooo useful! I love it. It has helped me out no-end. Thank you for producing it.

Second, as a follow-up to this thread:

I run my site through Pingdom to check page speed. It produces a nice little ‘waterfall’ graph of everything that the page requests and the load times for each item.

I have close to 30 plug-ins installed. Of them all, WP Add Custom CSS takes by far the longest to deliver its payload.

As an example, here’s a list of total wait times:
The theme (style.css?ver=4.3.1) 87 ms
Rapidology (style.css?ver=4.3.1) 63 ms
ShockSpots (front.css?ver=112) 69 ms
AssociateGoliath (post.css?ver=20151129091707) 68 ms
ShortCodes Ultimate (box-shortcodes.css?ver=4.9.9) 77 ms

There are more but these are typical. No other plugin shows times markedly different from the above, except:

WP Add Custom CSS (?display_custom_css=css&ver=4.3.1) 760 ms

So just like the OP, WP Add Custom CSS seems to be showing huge load times: 10 x longer than all others.

One thing I’ve noticed (and I’m not a plugin developer, so I can’t be sure I’m understand this correctly or be sure it is significant) is that yours is the only URL that I have installed to use a URL parameter immediately after the website’s domain name to obtain its CSS.

I’m guessing that this is because you are calling plugin code to query the database to dynamically obtain the CSS rather than referencing a saved, fixed file. (Or am I talking rubbish?!)

If I’m right, would it explain the 10 x longer issue?

Could the plugin be written to write a fixed file using a unique ID every time it is changed? (Caching)

Please understand that I am not a plugin developer so I appreciate that I could be talking utter tosh! Or going against WordPress programming standards. I’m just adding to this thread as I, too, have noticed this issue and would love for it to be truly resolved.

Thanks.
James

PS I don’t understand why all plugins seem to add the ?ver param to the end of their URLs. Doesn’t this prevent caching and slow them all down?