I figured out so far that AMP HTML greatly supports speeding up JavaScript, CSS and generally speaking rendering of the page.
However, yet another important speed topic in my experience are images.
How does AMP HTML tackle this issue such that images are perfectly compressed and resized for the current viewing device (tablet, mobile) and bandwidth (WLAN, 3G, Edge)
AMPs' image element amp-img supports the srcset (including support for the w modifier not natively available in Safari) and the sizes attribute in all browsers, so you can use modern responsive techniques to select the right image.
For now AMP itself does not do any image optimization itself. We might potentially start adding srcset attributes to image that don't have it on the proxy layer, but for now this is not happening.
Brief mention on this GitHub page:
The AMP HTML runtime can effectively manage image resources, choosing to delay or prioritize resource loading based on the viewport position, system resources, connection bandwidth, or other factors.
Basically the javascript library will be smarter about when it asks for image resources, which is a step up from what browsers do now: i.e. load all images in the background. This would be a more efficient use of available bandwidth.
Related
I'm building a new app with this great tool and i have a question to solve.
What is the best way to handle imnage size for multiple scren and multiple devices.
Apple = retina and non-retina
Android = ldpi, mdpi, hdpi, xhdpi, xxhdpi and tablets (all this with multiple screen resolution)
BlackBerry10 = one resolution (but not equal to the others)
WindowsPhone8 = one resolution (but not equal to the others)
For this case, what is the best way ?
Use SVG images (Optimizacion, perfomance, size of app) ??
Dedicate CSS tags for device pixel ratio (CSS Image Replacement) (the designer can kill me :smile: lol ) see the list http://bjango.com/articles/min-device-pixel-ratio/
CSS Sprite sheet
Another way
Before the decision, think in what is the best to apply in all devices.
Thanks in advance
There really isn't a single way to do this since each implementation of an image will require a different approach depending on its purpose. SVGs are great but not everything works as an SVG.
Media queries will be your ally.
See this: supporting multiple resolution and density of images in phonegap
and this for an alternate approach: Angular.js data-bind background images using media queries
There are also some nice polyfills for the html5 picture element which you might find useful.
See: https://github.com/scottjehl/picturefill
...and its angularjs directive implementation https://github.com/tinacious/angular-picturefill
I can't find an answer to this question, when the browser takes an SVG from the cache does it re-compute the xml or not, does it store the 'IMAGE' that it has already created? (How?)
I would've have thought not, but then I've noticed how fast repeated svgs load.
I've also noticed slowness on a page logo (in mobile browsers) which make me think THEY re-compute the SVG, so i've moved to PNG's (which are obviously cached) for mobile to save a lot of computational work for the low end phones.
So maybe, does the answer depend on the browser / browser type / browser settings?
*my svg's are compressed svgz's by the way
Sometimes it does and sometimes it doesn't. Most browsers go to some effort not to rerender things unless they have to. There is a buffered-rendering property in SVG 1.2 Tiny that may help if you're using Opera, other browsers try to do things automatically without requiring such hints though.
Browsers generally don't cache SVG content as a simple bitmap though. They do cache things like the absolute position and size of shapes and text with transforms applied, the css tree structure, gradients etc and then use this information they can redraw the content much more quickly than having to work it out each repaint. Such information allows browsers to copy with javascript and SMIL animation of parts of the SVG content as well as user scrolling.
i'm buildling a website and I want to create a translucid menu. I know that .gif image types enable transparency, but from my experience, not translucidy(anything between being transparent and opaque) - by default it seems to set the opacity to 100%, ie a solid image without any translucity/transparency.
I'm not sure if the issue is with the file type, or with how I'm exporting my menu. If it's worth anything, I'm using Fireworks to create and export my menu.
As is, I'm exporting my seperate files for my menu as .pngs, which seem to support translucent images, but I know that I'll be wanting to reduce the file size of these images soon, so is there a better alternative to getting a semi-transparent image other than using the .png file type?
Thanks,
Patrick
I'd say PNG is probably the best bet. The more modern browsers (read: not IE6) understand the 8-bit alpha channel it provides, whereas GIFs just have the transparency key.
Often these days, the bottleneck on sites isn't the size of the image (either in dimensions or in data) but rather the number of requests that it takes to load a page. More modern website designs try to pack as many images into one using techniques like CSS Spriting (woot.com, most of google). The other bottleneck is often not setting caching up correctly, forcing return visitors to reload a bunch of stuff.
You'll see google's various pages caching everything it can, and reducing the number of things a single page needs to download (combine all Javascripts into one, all CSS stylesheets into one) so that the browser is make 2 and 3 requests instead of 15-20.
I'd go with PNGs, and look into CSS sprites and caching as an alternative optimization.
See here for an example of an image sprite used on google's homepage.
I am benchmarking a custom brower and want to benchmark the rendering speeds of different types of images (gif, jpg, png) of the same file size to see which of the image formats this browser renders the fastest.
My process was just to have a simple seperate HTML page for each type of image and just use a Javascript counter before it is rendered and and after to measure the browser's rendering speed of that specific image.
Any thoughts on this process? Any thoughts on how to improve it?
Well, it's difficult to get meaningful generic results that way. You're measuring a combination of loading html, javascript and an image. Depending on where you're loading them from, you're also measuring the disk or network cache. The image rendering code is going to have some startup time, is dependent on a memory allocator and possibly garbage collection. Then there is image size, color depth, amount of compresion, number of images on the page, scaling, the influence of style sheets, the resolution of the javascript timer. Oh, and are you rendering to a visible part of a window, in a layer, or off-screen.
But don't worry, you'll be able to come up with a usable test. For your specific situation. Or the differences might even be very clear.
The Firefox Firebug plugin YSlow is pretty good
What are some best practices on enabling a web application to support multiple resolutions? Specifically resolutions that are wide-screen vs. normal aspect ratio.
It doesn't seem like there is an easy answer - other than simply supporting a few fixed resolutions and using some absolute positioning to get the layout to work correctly.
This of course gets even more difficult to make it cross browser.
Does anyone have any good resources of this problem?
You can always try to use a liquid layout structure where the width of your elements are scaled proportionate to how wide their browser window is.
here is a good article explaining different layouts including liquid layout.
http://www.maxdesign.com.au/presentation/liquid/
PS. the above mentioned site (maxdesign.com.au) is using liquid layout itself, so try and change the size of your browser when reading the article.
One fast, simple, fairly robust way is to use a framework like Blueprint or 960gs to lay out the site. They're browser-independent so you don't need to worry about that, and they make most column layouts pretty easy.
They both work on the idea of creating a fixed-size container somewhere between 900 and 1000 pixels wide for your content. Most people run in at least 1024x768 nowadays. If you need more width than that for your content, you're probably doing it wrong.
The one area where ~960px might not work is mobile phones... but that's what mobile stylesheets are for, right?
In Opera and Safari (esp. their mobile versions) you can use CSS3 media queries, which let you declare completely different styles for different screen resolutions.
This can be emulated in other browsers using Javascript – Alistapart: Switchy McLayout
You can use percentages to set width and heights also, but this is also difficult sometimes.
You have two options here:
Fixed Width Layout
Flow Layout
Both have benefits and drawbacks, and in the end, it's a design decision as to which is the best choice.