Feeling proud: WP YouTube Lyte got downloaded for the 100000th time today around 16h30;
In the meantime I started work on version 1.2.0, the main new feature being support for responsive design. It will probably be released in the 2nd half of July, unless you want to beta-test that is.
Anyway, thanks for all the downloads, here’s some Underworld (“Glam Bucket”) to chill out to on this lazy Sunday evening:
With the latest release of WP YouTube Lyte I fixed a problem where iOS users had to click twice to view a LYTE-embedded video; once to activate the iOS YouTube player and once to start the actual playing. On Android that problem does not exist, as LYTE embeds can be played inline in the browser.
Based on my own tests however, performance and quality aren’t always optimal when compared to the experience the native YouTube app provides. So now I’m wondering; wouldn’t it be better to not only detect iOS, but also Android and have both of them play in their respective a native players, even if on Android this isn’t an absolute requirement?
Advantages:
Disadvantages:
What do you think? Speak now or be silent forever!
And let me throw in a vid (Spiritualized with “Hey Jane” live) just for the heck of it;
Yesterday I released WP YouTube Lyte 1.1.5, which amongst other things has a workaround for the bug that required 2 clicks to play an Lyte-embedded Youtube on an iOS-device. The reason for the bug: WP YouTube Lyte replaces the “lyte player” with an autoplaying YouTube embed upon the first click, but Mobile Safari does not allow any media to autoplay. 1.1.5 now checks for the useragent (yeah, I know) and immediately adds a normal YouTube embed instead of the Lyte one if that useragent contains the strings iPhone, iPad or iPod.
So there you have it, only one click to hear and see this great “Here we go Magic“-clip on your iPad.
So audio-only and playlist embedding were broken due to changes at YouTube’s side, but version 1.1.4 fixes that.
Some information for those users that implement WP YouTube Lyte’s audio-only embedding feature; it got broken because YouTube started to enforce the minimal player size they recently added to their TOS. Audio-only is, for many reasons, something that YouTube doesn’t want to support and indeed might even want to block, so this might break again. So if you want to be on the safe side or if you just don’t want to piss YouTube off, you probably should reconsider doing audio-only.
That being said, here’s a nice audio-only track for your audio-only ears to celebrate this new release;
[Update: this indeed got fixed with 1.1.4]
So audio-only embedding is broken due to YouTube enforcing the minimum embedded player size that has been added to the TOS recently. I’m working on a fix for this, expect 1.1.4 soon. And if you’re impatient (or want to help), you can always download the development tar-ball here.
I’m not a developer, I’m just a random guy who was lucky enough to be around when the web started to happen, back in the nineties. And over the years I might have learned a bit about web development, but still I’m not a real developer. And yet, there I am with two WordPress plugins, fiddling with PHP and JavaScript. I’ll let you in on what’s not really a secret; I’ve made some ridiculous mistakes while coding those plugins. Trial and error, you know. Testing, fixing, releasing and getting feedback. Especially getting feedback!
Real users telling me it doesn’t work, asking for extra features or making proposals to make it better overall, that what I thrive on. The latest example; JavaScript namespaces. Not being a developer means that I know as much about coding patterns as I know about cows. I just hit the keyboard real hard and hope the browser understands what I throw at it. Until a good friend told me to use JavaScript namespaces, to avoid conflicts with other people’s JavaScript. And a week later someone wrote my software just didn’t work any more and I had to start digging and found a JavaScript conflict that was introduced with a new version of AddThis
And those are the moments one grows, as a developer; you start searching for information about scope, anonymous functions and namespaces. You try, it doesn’t work and you dig some deeper, until you stumble on a great question and answer on Stack Overflow with a link to a very detailed article about JavaScript coding patterns. So you go back into ‘vi’ and start changing the code once again and than all of a sudden you have a working version, which your Polish user confirms fixes the problem and you learned a lot while bugfixing.
So kudo’s to all you guys & girls for the great feedback, you rock! Here’s WP YouTube Lyte version 1.1.3 to thank you.
So stupid me made a (smallish) mistake when working on 1.1.0, which caused WP YouTube Lyte (rapidly approaching 80.000 downloads, thanks guys & girls) to load immediately instead of waiting for the “document loaded” event (lazy loading). That got fixed in 1.1.2 (which also loads the CSS differently, resulting in 1 file less to request), but the mistake did get me to re-investigate performance.
Exactly how fast is WP YouTube Lyte nowadays? I fired up some webpagetest.org IE9-instances in the Amsterdam node to compare this WP YouTube Lyte powered post on my test-blog with an identical blogpost with default YouTube embedded video. These are the jury’s results for the fastest of 10 runs in both cases (click on the image to actually see the details):
The main figures to compare (normal YouTube embed vs WP YouTube Lyte):
So using WP YouTube Lyte instead of normal YouTube embeds results in less files to download, less data to transport, the page being ready for interaction quicker and having everything loaded a whole lot faster. These figures are for a single YouTube on a page, but the impact is all the more important if you have multiple video’s on one page (e.g. a category or tag-page for “music” or “videos”) off course.
The full comparison based on 10 tests on both pages:
| YouTube embed (full results) | Lite YouTube Embed (full results) | |||
| doc complete | fully loaded | doc complete | fully loaded | |
| min: | 1612 | 3808 | 1047 | 1385 |
| median: | 1918 | 4631 | 1191 | 1524 |
| max: | 3221 | 5110 | 2078 | 2881 |
So there you go. When in doubt, check these stats and then go install WP YouTube Lyte, because after all speed matters!
You can do great things in JavaScript; accessing the DOM and adding, changing or removing nodes as you please. It is exactly that technology that WP YouTube Lyte is based upon; the PHP-part writes out an almost empty div’s with className “lyte” and with as id the YouTube ID, which the JS-part finds after the main document has loaded to render the “LYTE player”. Great for performance, so I was pretty surprised when DerTux, one of WP YouTube Lyte users wrote;
BTW, Google Page Speed dislikes Lyte:
“The following JavaScript call stack (executed 4 times) caused reflows that took 52 milliseconds: @wp-content/plugins/wp-youtube-lyte/lyte/lyte-min.:1:0“
Although 52ms for a page with 3 “LYTE players” is minimal when compared to loading the same page with the full embedded YouTube player, the above statement bugged me enough to search the web for information about reflows and how to prevent them. Some of the more interesting articles:
And this video by Paul Irish does a great job explaining reflows:
WP YouTube Lyte 1.1.1 will get pushed out in a couple of days (Thursday, probably) and will ship with these performance optimizations (and a fix for a regression which causes some styles not to be applied any more).
Nope, 1.0.0 wasn’t WP YouTube Lytes final destination, the train has left that station to arrive at version 1.1.0 yesterday. Main new features include:
I’ll leave it to Avi Buffalo to show you how the new UI looks like:
High performance YouTube video, playlist and audio-only embeds which don’t slow down your blog and offer optimal accessibility.
Next stop: 1.2.0. Any feature requests?
On a blog that uses WP YouTube Lyte which I happened to stumble across, the following warning was displayed:
Hey! If you’re browsing in Firefox, there’s a very good chance that you won’t see youtube / video embeds.
As I really don’t like bugs but couldn’t reproduce any issue myself, I contacted the blog’s owner to find out what was happening. The description of the problem was pretty confusing:
The still shot/first frame of the video is there with the play icon, so things look hopeful, but when you click on the play icon the entire video disappears from the page. Page structure / layout does not change, but you are left staring at a blank white box where the embed should be.
A white div of death, really … Anyway, to cut a long story short, the misbehavior was caused by “Karma Blocker“. This Firefox addon “blocks resources based on their karma”, using a ruleset that scores behavior to blocks banners, trackers and also WP YouTube Lyte (or rather, the YouTube iFrame). Apparently the combination of the bad karma of JavaScript and the iFrame triggered the blocking mechanism.
I couldn’t code around Karma Blocker and chances are small the default configuration will give YouTube iFrames better karma, but the next version of WP YouTube Lyte (1.1.0, to be available soon) will display a simple message kindly letting users know they might want to adapt their Karma Blocker’s weightings.
But why is karma punishing me?
