Updated: Google Images does not use <canvas> any more.
I noticed Google Images is using canvas to render images. <img> is used as a fallback for browsers that does not support canvas.
<a class="rg_l" style="..." href="...">
<canvas
id="cvs_NcG8skPEDu7FWM:b"
style="display:block"
width="83"
height="113">
</canvas>
<img
class="rg_i"
id="NcG8skPEDu7FWM:b"
data-src="http://t0.gstatic.com/images?q=tbn:ANd9GcQCB5NEbEUQhtmFI098HLSkfmoHTBtUfERUNkNKrhgFbtFBxZXY9ejXn_pUGg"
height="113"
width="83"
style="width:83px;height:113px"
onload="google.isr.fillCanvas(this);google.stb.csi.onTbn(0, this)"
src="http://t0.gstatic.com/images?q=tbn:ANd9GcQCB5NEbEUQhtmFI098HLSkfmoHTBtUfERUNkNKrhgFbtFBxZXY9ejXn_pUGg">
</a>
What's the point of using <canvas> rather than <img>?
Maybe it gives them more control over the contents of an image.
You can analyze color range of an image, prevailing color, even its content (given smart algorithm).
You can also perform per-pixel modifications — change brightness, contrast, gamma, etc. (not sure why they would want to do this; perhaps for some future use).
You can also rotate an image (on browsers that support canvas but not CSS transformations; see, for example, this demo of my fabric.js).
Several mobile devices have a limit on the number of image resources on one page. For example, Mobile Safari stops loading images after ± 6.5 MB of images have been loaded.
As mentioned in another answer, by using <canvas> instead of several <img> elements with external files as their src, Google can load all the images in one request (which is obviously better for performance) — but it also works around this limitation.
You can easily load all the images in one request or even embed their source in the page without inflating the source with base64.
You can make copies of images in JS without waiting for the cache.
maybe this was done because of too slow scrolling / some rendering issues on a page with lots of pictures?
Related
I'm currently trying to display PNGs with react-three-fiber but when I set a texture with a transparent background it doesn't show.
I've tried many things but noticed that if I take the base64 of the image and load it into a img html element, it doesn't display either, otherwise, if I put it as an href for an a element, I can download it with no issue.
Here is a live exemple where you can download the file but not load it into an img:
https://codesandbox.io/s/kind-elion-tznyx?file=/index.html
You may open the sample in a separated tab as codesandbox is preventing file download from the reduced window.
If anyone ever experienced this, maybe something in the base64 is wrong.
Testing this same demo in Safari, it will work correctly. In Firefox and Chrome it does not. Data URIs are best used for small images — they add a ~30% size penalty to the data they store, and a significant amount of extra processing is required to display them. Browsers including Chrome impose limits on the supported length of Data URIs for this reason, see https://stackoverflow.com/a/41755526/1314762 for details on those limits.
Let's say I have an image with actual size of 200x200 pixels. I insert it into a HTML page like this:
<img src="some.jpg" width="50" height="50">
Suppose there's no CSS styling for this image.
Will it be displayed consistently across all browsers and devices like a 50x50 image? Are there any exceptions?
This style is supported among all of the major browsers (IE, Firefox, Opera, Safari, and Chrome)
Keep in mind that when doing this, the user is still forced to download the full size image before it is rendered in the size you specified! If it is a particularly large image, it may be wise to downscale it with an image editor before you upload it.
The user is still receiving the original file but the browser is altering it through its respective rendering methods.
The only exceptions to this rule, and this isn't necessarily due to browser rendering but may be helpful to keep in mind, is that HTML 5 no longer allows for you to adjust by percentage -- you can only adjust by pixels (as you already are)
I have a very basic HTML website with images displayed with the following code:
<center><img src="style/images/istress.jpg" height="400" width="400" alt="photo by Kristin" class="attachment" /></center>
Is it possible to also optimize the images for mobile? Currently they are stretched/skewed when I visit the site via Safari mobile browser. Not sure if I'm able to set another size with just HTML.
Use the GD library to provide multiple sizes, even on the fly if you want to be fruity :)
There are several methods of optimizing image sizes from dynamic resizing to heavy compression and I will leave this to you to investigate, good link for some light reading is:
http://salman-w.blogspot.co.uk/2008/10/resize-images-using-phpgd-library.html
If you are not massively technically capable you could use http://www.imgix.com/ which I have used on a few occasions. Quite reliable too.
Do background images and embedded images take about the same time to load on a HTML page provided they are the same size? If I am to use the same image twice in a page - once as a background and once as a normal embedded image, which loads faster?
For making a website compatible with screen readers, what's the best way to include an image? Are background images read well by screen readers or do they simply ignore the background images?
Do background images and embedded images take about the same time to load on a HTML page provided they are the same size?
I would say yes, but I think it also depends on how they are loaded. There used to be a practise called image pre-loading. I never did speed tests personally to know if it was really benefitical.
For making a website compatible with screen readers, what's the best way to include an image? Are background images read well by screen readers or do they simply ignore the background images?
Screen readers do not announce that <body>, <div>, etc has a background image attached. There is no magical place for an alt attribute in this case. You need to keep in mind that you're keeping good contrast between your image and your text color. WebAIM has a great color contrast checker, in my opinion.
If you are using CSS to position text over an image that's used as background, so you can give it an alt, don't. That image probably should have a null alt (<img src="..." alt=""/>) anyhow.
If you use an image both as background AND as image (i.e. Using the same image twice) you technically only need to load that image once, assuming your images are properly cached...
That is once you loaded an image with a cache header, or that image is downloading, the browser will either load it from the cache or wait for that one image to finish loading.
As to whether background images and embedded images take about the same time to load. Let's get some context. As per google: https://developers.google.com/speed/articles/browser-paint-events
Finally, notice that each image itself renders progressively, so that
the the user begins to see the image content before the entire image
has finished loading. Modern browsers render images in HTML tags
progressively. By contrast, many browsers do not render images
specified using CSS background-image attributes progressively. To
enable progressive rendering of images, use an HTML tag instead
of a CSS background-image attribute.
So an image using the <img> tag will load faster and not hold up the DOM from being ready unlike an inline css background-image in older browsers which could slow things down.
However, the caveats with progressive rendering of an <img> are that, if your image is not fully loaded when the widow.onload event fires (which is almost always true for large images), it makes for a rather ugly progressive rendering, as well as causing a paint reflow when the image is set as responsive using auto-width and/or 100% width.
To make inline images load much faster and in a much nicer way, what I did is:
First, preload them extremely early as css backgrounds in AND on the <head> of the page. You can start preloading some or all of your css images too that way, before your css file or body have been parsed.
Second, to go around the other drawbacks, I use a javascript lazy-load-ish method to hide the image on the interactive event before the window loads.
And finally, bring the image as a fade-in once the css-called image has finished loading.
You can see a live example at: http://www.nptr.net/1614
So while an embedded image is best. If you care about the best speed for your page load, I highly recommend to preload large images early via css background(s) in the head, especially if you must use them as backgrounds right away.
That is because otherwise, images in your body will have to wait until both your css file(s) and synchronous javascript(s) are fully received, until the browser actually starts retrieving them. Which generally incurs a 100 to 500ms delay, with the worst delay being on the first page load.
What is the reason for the granularity of images in HTML documents?
I have scanned some documents and created corresponding JPEG images with the following properties:
image size: 2452 x 3508 pixels
resolution: 300x300 ppi
JPEG, RGB
and included them into an HTML document with: <img src="image.jpg" height="100%" />
I have opened the web page on a big monitor and on a notebook.
In both cases the quality of the images is very bad. They are too granular so that the text is difficult to read. Although if you open them in the standard Windows image viewer you can see every small detail.
How to include an image into an HTML document without losing the quality?
You are scanning an image at print quality and displaying it on a screen that usually cannot handle more than 96 DPI at max.
Re-scan the image using a lower DPI setting and don't try to display an 8 Megapixel image in a browser window.
This may seem counter-intuitive to what you wish to accomplish, but its not. You will never get a scanned image to display on a computer screen as if it where print quality. (Until we all have retina quality displays for monitors)
Try removing height="100%" from image tag.
<img src="image.jpg" />