iwords

I’ve done some more testing on this and it appears that everything is fine up to and including version 2.8 of the plug-in, but in 2.9 onwards the title tags are empty.

I’m implementing a workaround in the theme for search pages for now, but here’s a link to a page that should generate a 404 with an empty title tag.
https://www.testdriven.co.uk/notfound

We found the option to exclude particular scripts from being deferred was necessary to allow this plug-in to work correctly with the AMP plug-in.

Without excluding the AMP script, AMP content doesn’t display correctly on our sites.

With this option removed, we can no longer use the Speed Booster plug-in.

Compatibility issues arise between plug-ins all the time, and this option was a necessary mechanism to resolve them. I’d urge you to reconsider its removal.

Ah, that’ll be the Speed Booster Pack. I’ve added an exclusion for that script and it works now.

Thanks for your help.

Oh, I fully expect it to have very limited real-world performance benefit, but not having it defer’d or async’d does seem to upset Google.

Now that Google has openly declared that a site’s measurable performance is being considered a factor in its ranking, I think it’s only going to become increasingly important that site owners optimize whatever they can – even if that means making a few changes just to please Google.

So, it’s good to see it’s being considered. And thanks for your help so far.

That seems to stop the CSS from being render-blocking, thanks!

Is there anything we can do to try to address this issue with https://stats.wp.com/e-201446.js being considered render-blocking?

Is there a way I can make it add a defer or async to the script tag, for instance?

Sure, I’ll try my best!

Speed Booster, among other things, looks through the list of resources (CSS and JS) that are enqueued using wp_register_style() and wp_enqueue_style(), plus wp_register_script() and wp_enqueue_script(), and provides the option of deferring, minifying and/or inlining them.

This makes Google PageSpeed happy. ??

As long as the resources have been included (‘enqueued’) using wp_enqueue_style() and wp_enqueue_script() – which seems to be the way the WordPress guys want us to load CSS and JS files anyway – Speed Booster can intercept and place them in a more optimal position.

I’ve assumed by looking at the position of Jetpack’s CSS and JS files, that they aren’t being loaded by wp_enqueue_style() and wp_enqueue_script(). This means Speed Booster doesn’t know about them, so can’t do anything to optimise their loading.

If they were enqueued, it shouldn’t affect anything for most people, but those that use caching or optimisation plug-ins like Speed Booster should find they become available for optimisation. In the case of Speed Booster, it would be able to inline the jetpack.css file and it may also fix the problem of PageSpeed complaining about the stats.wp.me JS being a render-blocker.

Hope that makes sense; not trying to teach anyone to suck eggs!

I’ve started a thread in the Insights group, but I don’t hold out much hope I’m afraid.

On the subject of the jetpack.css file, it does seem to be included by a conventional <link rel line, and this appears to be preventing the Speed Booster Pack from inlining it.

I presume this is happening because it isn’t enqueued like the other CSS files – is it possible this could be changed in a future release?

Thanks for the response, Jeremy.

I’ve spent some more time on this and I’ve discovered something strange: PageSpeed only complains about it on certain pages. Here’s an example:

https://www.testdriven.co.uk/ford-adds-20-litre-tdci-and-25-litre-duratec-to-kuga-range/

If you run that through PageSpeed, on the Desktop tab it says:

Eliminate render-blocking JavaScript and CSS in above-the-fold content
Your page has 1 blocking script resources and 2 blocking CSS resources. This causes a delay in rendering your page. Approximately 62% of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

Remove render-blocking JavaScript:

https://stats.wp.com/e-201445.js

Optimize CSS Delivery of the following:

https://www.testdriven.co.uk/…-content/plugins/jetpack/css/jetpack.css

But if I run another page through PageSpeed:

https://www.testdriven.co.uk/skoda-octavia-greenline-hatchback/

…there’s no mention of any render-blocking scripts or CSS. Yet both these pages use the same theme code to display.

Strange.

Thanks, Peter

That won’t notify Google that anything has changed, though. Google will see that the lastmod date on existing pages hasn’t changed and not bother to crawl them.

Surely the point of the lastmod date in the sitemap is to say to Google “this page fundamentally changed on this date, you might want to schedule a re-crawl to pick up the changes.”

Simply resubmitting the sitemap with the old dates won’t trigger anything.

No?

I think I’ve unravelled this issue now.

The short version appears to be that Jetpack has *never* worked for this site as far as OpenGraph is concerned, and that’s why the additional function had been added to the theme.

In class.jetpack-post-images.php lines 190-206 contain a function that strips out attached images if they have not been inserted in the body of the post. For this particular site, images are never inserted, they are left as attachments and displayed by the theme separately in the right margin. In effect, Jetpack has always been stripping out the images before generating the OG tags, so we’d obviously tacked on our own code in the theme to fix this.

In the latest update for Jetpack, you’ve added a fallback that uses https://wordpress.com/i/blank.jpg as the og:image if no other images were found. With all the real images stripped out and Jetpack adding a new fallback image, that’s all that Facebook had to play with, hence the blank images.

What I’m going to do now is disable Jetpack’s OG functions and we’ll handle it ourselves within the theme’s functions.php.

For the moment, I’ve done this by editing the plug-in’s files, but is there an easier way I can do this? A filter I can add to the theme’s functions.php, perhaps?

That’s the default twitter:site value, as it appears on all Jetpack sites.

But that’s wrong, isn’t it? So, for my site, I need that to be @TestDrivenUK. Can this be changed somewhere, other than editing the code?

There was a function that added extra meta fields which I’ve now stripped out. I’ve re-upgraded to 2.6 to test it, and now the meta fields that Jetpack is placing in the head are:-

<!– Jetpack Open Graph Tags –>
<meta property=”og:type” content=”article” />
<meta property=”og:title” content=”New Volvo V60 Polestar announced” />
<meta property=”og:url” content=”https://www.testdriven.co.uk/2014-volvo-v60-polestar/&#8221; />
<meta property=”og:description” content=”The new Volvo V60 Polestar has been revealed. Although available globally in both saloon S60 and estate V60 guises, only the estate model will be offered in the UK.” />
<meta property=”og:site_name” content=”TestDriven” />
<meta property=”og:image” content=”https://wordpress.com/i/blank.jpg&#8221; />
<meta name=”twitter:site” content=”@jetpack” />
<meta name=”twitter:card” content=”summary” />

So, to my mind, the twitter:site value is wrong, and the og:image value isn’t finding the attached images.

Just to be clear, this site isn’t hosted on wordpress.com.

I’ve reverted to Jetpack 2.5 for the moment, but even with that version it’s now adding this meta tag to the <head>

<meta name=”twitter:site” content=”@jetpack” />

Where is it getting @jetpack from? I can’t see any settings where that’s stated.

There are no other plug-ins that generate OG tags, but to check I disabled all other plug-ins – the OG:image tags in the <head> were still incorrect.

The incorrect og:image tag is in the section immediately after the <!– Jetpack Open Graph Tags –> comment, so it’s definitely being placed there by Jetpack.

Just to re-iterate, this incorrect og tag only appeared after I updated Jetpack.

For the sake of clarity, the problem affects all posts, not just those made since Jetpack was updated.

One thing that this site does that is perhaps different to other sites – images aren’t embedded into the body of the post, they are uploaded but left as attachments and the theme displays them separately in the right margin.

However, the previous version of Jetpack handled og:image tags correctly, it’s just a problem with the new version.

Hope that helps track it down.