Josh Levinson

That report shows that almost 85% of your load time is due to assets – split between scripts, images, css, and html. Again, as I noted above, this plugin loads no assets unless it is on a product page.

One very important thing to note when using the P3 profiler is that it does not immediately differentiate front end load time vs wp-admin load time. When it reports page load time, it inaccurately gives an estimate based on the average of both front-end and wp-admin, which is not relevant when you’re trying to determine page load time for visitors (which I assume is your goal).
A good way to view the difference is to go to the “Detailed Timeline” tab – /wp-admin/tools.php?page=p3-profiler&p3_action=current-scan#p3-tabs-6

This will show you not only the load time on a graph per plugin, but more importantly where the load time occurred. On my scans (I performed ~10), this graph mirrors what I’ve been saying – that this plugin causes no increased load time on the front end of the site, except for on a product page.

I installed/activated all of the plugins you listed, and still got different results – my page load time is 0.5s, with this plugin only causing 0.04s load. I recommend running your site through https://tools.pingdom.com/.

You can look at the source code of the front page (and any other non-product page for that matter) and notice that no assets whatsoever are loaded from this plugin.

Let me know what you find out from running a page load test; in the meantime I will see what I can do from my end.

What page did you run this scan on? I noticed you did a one-page scan, not an automatic scan.

The fact that your results differ from mine (I ran the same profiler on a site of mine) suggests that the results you see are due to a server or site config issue. I’m surprised that the other spikes you see are so high. A good load time is less than 1 second. Your caching plugin causes increased load of > 2 seconds; it is designed to decrease load time.
I’d be interested in a full result of the profiler though. Can you link to the spreadsheet of this profile run?

@phpmypython – He didn’t mean for localization. He meant for actually defining the variables you need in javascript. That’s the other (purposed) reason of wp_localize_script.

In other words, in gravityform-placeholder-addon.php:

add_action('wp_enqueue_scripts', 'gf_placeholder_addon_script_enqueue');

function gf_placeholder_addon_script_enqueue() {
	$placeholder_js = plugins_url( basename(dirname(__FILE__)) ).'"/jquery.placeholder-1.0.1.js';
	wp_enqueue_script('gf_placeholder_add_on', $plugin_url . '/gfplaceholderaddon.js', array('jquery'), '1.0' );
	wp_localize_script('gf_placeholder_add_on', 'gf_placeholder_vars', array('jquery_placeholder_url' => $placeholder_js) );
}

In your gfplaceholderaddon.js:

if ( support && gf_placeholder_vars.jquery_placeholder_url )
		$.ajax({
			cache: true,
			dataType: 'script',
			url: gf_placeholder_vars.jquery_placeholder_url,
			success: function() {
				$('input[placeholder], textarea[placeholder]').placeholder({
					blankSubmit: true
				});
			},
			type: 'get'
		});

I made a couple of edits after my initial post, so make sure you don’t rely on the initial notification of my post for accurate advice.

The plugin doesn’t require PHP 5.5. That is just the version I use on my server and local development environments. I tested it down to PHP 5.3 after the issues were reported. I will not be testing PHP 5.2, as it has been unsupported since 2011.

Hey Will,

I addressed your requests in version 2.0.

Thanks!

Hi again!

I’ve pushed another update – 2.0.2.
I believe the discrepancy between it working for me and failing for you is a difference in server setup – probably that I am running PHP 5.5 and you are running a lower version. Hopefully 2.0.2 will resolve this compatibility issue.

Thanks for your patience!

Hi again!

I’ve pushed another update – 2.0.2.
I believe the discrepancy between it working for me and failing for you is a difference in server setup – probably that I am running PHP 5.5 and you are running a lower version. Hopefully 2.0.2 will resolve this compatibility issue.

Thanks for your patience!

Update released, thanks for the notification!

Update released, thanks for the notification!

Sorry about that. It will be fixed in a hot fix update in the morning.

Sorry about that. It will be fixed in a hot fix update in the morning.

Hi there. So I ran the P3 profiler on this plugin (as of version 2.0) and it consumes only 0.04 seconds of time at any given point. The load time was only caused on the wp-admin pages, not on the front end.
Besides this, the plugin definitely never consumed 2 times the resources of WooCommerce. I tested before and after the 2.0 update, and it consumed a fraction of the resources WooCommerce does, and only in wp-admin. Load times have been decreased even more.

To hide the info of the person who asked the question, the css is:
faq-author{ display:none; }

The answerer’s info can be hidden with:
.faq-content .comment-author{ display:none; }