The way YouTube recommends you load a video is like so:
<iframe id="ytplayer" type="text/html" width="640" height="360" src="http://www.youtube.com/embed/Zhawgd0REhA" frameborder="0" allowfullscreen>
This loads the video as an iframe so they can detect iOS or other devices and deliver a swf or HTML5 player depending on what's necessary.
These snippets come from their Player API Demo. https://developers.google.com/youtube/youtube_player_demo
Unfortunately, in IE6-9 this causes serious slowdown - the browser seems to freeze up for as much as 5 seconds, even when the player is the only thing on the page and isn't set to autoplay. In addition, there's a touch of irony to this "demo" in that they aren't at all loading the player the way they recommend, and instead loading it via a custom written Google AppEngine/AppSpot app they put together - and it actually does load more performantly in the demo in IE than when one uses Google's recommended snippet.
Have others run into this? Is there a good solution?
Related
I want to know the benefits of using Picture tag vs the CSS media query in-terms of pure performance (website load time).
I am developing a website and clients are forcing me to use picture tag but I think both are same. Let me know your input.
<picture>
<source
media="(min-width: 650px)"
srcset="images/kitten-stretching.png">
<source
media="(min-width: 465px)"
srcset="images/kitten-sitting.png">
<img
src="images/kitten-curled.png"
alt="a cute kitten">
</picture>
or
using media query and targeting separate image tags.
Media query works this way:
Even when you are viewing a website in Desktop, it still downloads the styles of mobile.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
Picture tag: If you have 3 different images for mobile, tablet and desktop.
Picture tag will download only mobile device image when a page loads (when on mobile), it will neglect other 2.
If you want to test:
1. Write HTML code as you have above for 3 different images.
2. Once you are in desktop, load the page. Now you have a desktop image which you can see.
3. Disconnect the internet from your laptop.
4. In your browser responsive mode, keep reducing the screen
5. When it hits the tablet width, you will see the image won't be visible and it will be broken.
6. That means the image for tablet was not downloaded earlier when page load.
I think the accepted answer/question is lacking some real world contextual details. When talking about performance, we're usually talking about performance on slower devices such as mobile devices, not desktops.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
This is usually not a problem as desktops have faster processing and they don't run on data (larger bandwidth) unlike mobile devices.
The accepted answer never mentioned how CSS media queries behave on mobile devices - this method actually only applies the styles that satisfy the smallest media query. The reason why this method 'downloads' all styles on desktop is because of how media queries are usually written with mobile-first design, by setting a min-width criteria. So when loading the page in desktop, all your media queries would be satisfied thus they are all applied and the last one in the source order wins.
So in terms of performance on mobile devices, both methods are the same. Ultimately, the <picture> tag is still the most robust solution due to additional configuration options with the srcset attribute. However, sometimes you need to use CSS media queries instead of <picture> tags such as when dealing with background images.
Here's a recent guide from Google recommending CSS media queries for optimizing background images: https://web.dev/optimize-css-background-images-with-media-queries/
We've been taking payments online with 3D Secure enabled but a while ago we were getting so much negative feedback from mobile users because the Verified by Visa form in an iFrame was too big for the screen that we turned it off. I've been told that this is no longer financially viable and i need make it work properly for mobiles.
I've wrestled with numerous 'responsive iFrame' solutions but it seems to come down to the iFrame contents that are the issue (tables with hard-coded widths), which obviously I have no control over.
I've not found anything about a mobile-friendly solution after a few hours on the web.
Does anyone know if there is a responsive way to make 3D Secure usable on an iPhone for example?
I think the only way to solve this is to set the iframe’s width to accommodate the fixed width tables (400px should do it) and then apply some CSS to the iframe to scale the page so it fits the mobile screen size.
Here’s an example:
<iframe width="400px" height="500px" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="SagePayURL" style="-webkit-transform:scale(0.7);-moz-transform-scale(0.7);-webkit-transform-origin:top left;-moz-transform-origin:top left;"></iframe>
Honestly, I don’t know why VISA or Mastercard can’t have a desktop and mobile version of their 3D secure page.
I wanted to convert some few flash files to HTML 5 Based Videos, I tried using Google Swiffy which was much better than any other converters. The only problem is it doesn't have support for audio in Mozilla Firefox, android Browsers and Mobile safari browsers. Is there any way to manipulate the JSON data and make it work on all the browsers, if yes, how? if no, why?.
Clear explanation on how Swiffy works is much appreciated.
Thanks in Advance
I've found that a better solution is to separate the audio and animation and encapsulate each. For example, create an AnimationPlayer and an AudioPlayer. Within each of those, implement Swiffy and say Jplayer respectively. This way if you need to replace your swiffy animations with CreateJS sprites or whatever the next cool thing is, you can without breaking your other code. This also of course addresses the audio problem by using a well developed audio player that likely works and is maintained for all browsers.
Since the question was asked, the audio now works in Firefox (23) - the compatibility chart at the swiffy site stops at FF 15. Let's say "partially supported", because in both FF and IE9, the sound is apt to stop when animations get complicated. Works beautifully in Chrome, though.
Michael Prdescott's answer may offer some hope for iPads, which still don't recognize swiffy sound. But, I'm wondering how it would work - the user would press two buttons (one for sound, one for video)? Or the audio and video would load together and autoplay? Either way, wouldn't that make a mess (or at least be risky) when sound/video are meant to be synchronized?
I am trying to write a crawler in a bash to download images from bing. Everything works fine except the fact that bing loads only 30 images in the beginning (uses infinite scrolling) and hence I am not able to download more than 30 images using wget.
Any workaround to download more than 30 images from bing images at once.?
--
Thanks for any help. :)
Bing has an API, perhaps that would work better than screen scraping? It would certainly be more allowed/supported by Bing than screen scraping, and less prone to breaking changes as they change their offerings over time.
If you're really set on the screen scraping for whatever reason, you might try loading the page with debugging (such as with Firebug) and watch what happens when the infinite scroll is triggered. Then try to manually trigger it with code.
I've been playing around with the HTML5 video tag and I'm puzzled as to how best to degrade when you can't support a codec?
For older browsers (or IE) that don't support the video tag at all this quite is straight forward:
<video width="320" height="240">
<source src="vid.ogv" type='video/ogg'>
<source src="vid.mp4" type='video/mp4'>
<object>
<!-- Embed Flash video here to play mp4 -->
<object>
</video>
They will fall through and will receive the Flash version (or other alternate such as an image!)
How about when the browser does support the tag but not the codec - Like FireFox 3.5 for example - and I can't support OGG (possibly because I already have vast archives of H.264):
<video width="320" height="240">
<source src="vid.mp4" type='video/mp4'>
<object>
<!-- Embed Flash video here to play mp4 -->
<object>
</video>
All I get in FireFox 3.5 is a grey box with an x in it. This isn't exactly a great user experience for FireFox users! I can only think of using JavaScript to check for FF3.5 and change the DOM!! is this really the bad old all over again! ...or is there some part of the spec I'm missing out on like a 'novideo' tag?
An important part of graceful degradation is the querying capabilities... Dive into HTML5 is a great read... specifically, look at the video section. Relevant code here:
function supports_h264_baseline_video() {
if (!supports_video()) { return false; }
var v = document.createElement("video");
return v.canPlayType('video/mp4; codecs="avc1.42E01E, mp4a.40.2"');
}
Note: this does require DOM checking, but for capabilities and not browser signature. It's the right thing to do :-)
Once you know if the browser can support, you can show your video tag or pull up a lightbox or redirect as you see fit.
One really good way to tackle this problem is to use modernizer js library.Its really easy to use and quick.It can check HTML5 capabilities in the user's browser . Visit the site here : http://www.modernizr.com/
Video for Everybody's test page indicates that Firefox 3.5 can only play OGG. You might want to add a flash version if you really don't want to add OGG. VfE also does not use JavaScript, so it might be worth looking into.