Mastodon due to the decentralized nature can result in a significant extra load on your site if someone posts a link to it. Every Mastodon instance where the post is seen (which can be 1 but also 100 or 1000 or …) will request not only the page and sub-sequentially the oEmbed json object to be able to show a preview in Mastodon. The page requests should not an issue as you surely have page caching, but the oEmbed object lives behind /wp-json/ and as such is not cached by page caches. The solution; the WP Rest Cache plugin and one small code snippet (for now). A lot more info can be found in Donncha’s excellent post on the subject.
oembed
WP YouTube Lyte now parses normal YouTube links as well
I was just being a jealous guy, seeing how normal YouTube embeds (oEmbeds) got previewed nicely in WordPress 4.0 TinyMCE editor. This had been on my wishlist for a long time already and I looked into enabling that for httpv-links and lyte-shortcodes as well, but that turned out not to be that simple.
So I took the alternative approach, enabling WP YouTube Lyte to act on normal YouTube-links (a much requested feature anyhow) and thereby piggy-backing on the TinyMCE-improvement in 4.0. So there you have it; lyte video’s can be inserted using normal YouTube links and that will result in a (non-lyte) preview of the video in the visual editor content box.
1.5 as a number of other improvements and bugfixes, but you can read all about those in the changelog.
Have fun with this small Rick James like party-track to celebrate 1.5.0 (and my birthday, while we’re at it);
My YouTube is Lyter then YourTube!
The latest WP YouTube Lyte version came with support for responsive themes and added microdata for better search-engine discovery of your embedded video’s. But there were also some important improvements from a performance point of view;
- The title of the video (and the description, length, …) is now requested and cached server-side (the data is stored in the WordPress database, as post_meta, to be precise) and included in the HTML instead of getting that data client-side using JavaScript
- The LYTE player chrome (the play button -with 2 states- and the bottom control) is now fetched with one request for a CSS sprite (lytesprite.png) instead of 2 separate images
- And finally a lot of the player properties are now defined in CSS instead of being dynamically set in JavaScript, resulting a a significantly smaller JavaScript-file
But what are words worth, you only want to know if WP YouTube Lyte still out-performs normal YouTube embeds, right? Well, there’s nothing like a nice old-fashioned comparative webpagetest;org test to see where we stand!
| document complete | fully loaded | video only | ||||||
| time (s) | requests | size (KB) | time (s) | requests | size (KB) | requests | size (KB) | |
| Standard YouTube (page | result) | 1.757 | 10 | 167 | 4.718 | 13 | 483 | 8 | 429.8 |
| WP YouTube Lyte (page | result) | 1.021 | 6 | 79 | 1.353 | 8 | 100 | 3 | 22.9 |
So yeah, WP YouTube Lyte is more efficient then normal YouTube embeds, by a very large margin! Now go and preach to the unfaithful, because after all, doesn’t the world deserve Lyter YouTube embeds?
How to have normal YouTube-links handled by WP YouTube Lyte
Although by default WP YouTube Lyte only works with httpv or httpa links and hence does not act on normal YouTube links (which are instead auto-handled by oEmbed in WordPress core), you can easily change this behavior by adding the following code-snippet to your theme’s function.php or to a separate “helper”-plugin:
/** force wp youtube lyte on http://www.youtube.com url's as well */
add_filter('the_content', 'force_lyte_parse', 1);
function force_lyte_parse($content) {
$content=str_replace('http://www.youtube.com/watch?v=','httpv://www.youtube.com/watch?v=',$content);
return $content;
}
Now that wasn’t too hard, now was it?