I am optimizing a site. As suggested in this CSS-tricks article, I am planning to <use> SVG icons. I am a bit skeptical due to my use case.
Most of the icons are placed once(or twice) in a page for which SVG <use> is fine.
But there are two icons which has to be placed at multiple places(approx. 20-50 times each) in a single page. For this particular page, is it better to use PNG because PNG method will benefit browser caching?
Will SVG method bloat the HTML document with the same icons being repeated, say 50 times?
Please answer even if this sounds like a premature optimization. I am refactoring the existing site's code. I have already checked this similar thread.
Asking again because:
My particular use case.
Hoping things have changed in 2022.
Related
I just started to learn svg. One thing perplexes me is I find some site use svg/path to draw a text logo. Like this one:http://www.desiringgod.org/
The logo is pretty simple itself, however, the SVG it is using contain a horrendous <path> tag where there are lots of numbers.
I understand that with SVG we can scale the logo, but I don't see any difference if this logo is based on a .png file. So what really is the benefit?
Secondly, I don' think something like
<path d="M115.326252,8.93098333 L115.326252,16.3798167 L113.923083,16.3798167 L113.923083,14.96265 L113.878305,14.96265 C113.092947,16.0569833 111.560896,16.5939833 109.858654,16.5939833 C106.367752,16.5939833 103.855367,14.0609833 103.855367,8.63131667 C103.855367,3.20098333 106.367752,0.667483333 109.858654,0.667483333 C112.454152,0.667483333 114.454146,1.91331667 115.390858,5.21765 L113.771894,5.53931667 C113.007521,3.07148333 111.7296,2.12731667 109.943088,2.1273166 ....</path>
is written by human being. This must be generated by something, isn't it?
The benefits of using SVG logos over PNG logos are the following:
Scale to any size, perfect for responsive websites.
Look sharp on retina displays.
Don't lose clarity, except for very tiny sizes (same with PNG).
With PNG files you would most likely need to generate multiple resolution versions of the same image and hope that the original image is large enough to support the future display resolutions (8K for example).
And yes, the path is not written by a human being. It's a standard part of an SVG file. You could also do stuff like export SVG files as HTML5 canvas code with an ink2canvas extension in Inkscape.
Advantages of SVG:
Resolution Independence
Super-Accessible DOM Node-Based API
No Unnecessary HTTP Requests
Easy Interactive Scripting
Read more details on: Why Aren’t You Using SVG?
In here, I will describe some differences between using SVG and PNG from an application perspective:
SVG files are lighter than PNG files when deployed to your
application.
PNG is more efficient as far as UI responsiveness since the file is
already within your application, and there is no scaling needed, but it's heavier than your SVG file.
PNG gives a better focus to photographs or detailed images than SVG.
I personally use SVG for icons and logos and PNG for photographs or detailed images.
SVG offers a way to do full resolution graphical elements, no matter
what size screen, what zoom level, or what resolution your user's
device has.
So you write HTML? JavaScript? CSS? Good. Then you already know a lot of what you need to know to get writing SVG.
SVG actually uses an XML-compatible format to define its rendering shapes. Beyond this, you can actually style shapes in CSS, and make them interactive with JavaScript. Multiple JS libraries exist to assist you in this world, like D3.js and Raphael. Here's an example of an SVG element group (the Envato leaf).
The other benefit of SVG is,
When you use images in an html document with the tag, you are defining a file that the user's browser will request. This request will take up bandwidth and require more precious time to download. If your image is instead a set of dom nodes, it cuts that extra HTTP request out, making your website faster and more user friendly.
An SVG XML document of any complexity looks relatively archaic and complicated, and seemingly isn't nearly as easy as just using an image.
If I have to show one image many times on my HTML page, which is better from the point of view of site performance, many image tags with the same src URL, or many elements with the same background image defined in CSS? The first way, the browser should cache the image the first time it requests it, but there are still many requests to deal with. The second way, it seems to me there is just one request, when the CSS is parsed. Am I right in thinking that is more efficient?
Even in the case of CSS, the multiple background-image rules would still involve the browser making one web request & then caching the image. Exactly the same mechanics would be in place. The fact that the images are referenced in CSS rather than in HTML doesn't allow the browser to magically 'know' it already has the image without even checking the cache.
The primary difference between your two scenarios is that if you reference all the images in CSS, the CSS itself could be cached, which would represent a minor performance improvement, and your HTML files will be smaller. The improvement may or may not be substantial - it depends on many other factors such as how many image references we're actually talking about, whether your HTML files themselves are cacheable, how many page-views your users make on average, and so on.
All said, the CSS background-image is likely to be marginally better, but not for the reason you state. Whether you're talking HTML or CSS, you're still looking at one request followed by a bunch of cache-hits.
Suppose I am using a DIV element for which I can either add a background image or can replicate the same style creating a CSS3 gradient. Now, for Phonegap applications (where all the image files reside in the device itself), which option is better to go for.
I am asking this because I saw somewhere that the gradients takes some computation time where using image may create a loading time issue. But for Phonegap apps, the image load time issue may not be there. So, maybe just using the image be a better option here?
According to an article on the Webkit Wiki, images perform better:
Sometimes it's tempting to use webkit's drawing features, like -webkit-gradient, when it's not actually necessary - maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer's computer to the target's CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) - otherwise, static images are always faster. On very low-end platforms, it's even advised to use static images for some of the text if possible.
Source: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages
Of course, you have to balance that CPU time with the extra time it would take to load the image from the server. Also, for Internet Explorer, filters are extremely slow, especially if you have many on one page.
Bit of background
I've been producing a Flash-driven webcomic for three years now, incorporating some basic animation, a synced soundtrack and zoom-drag page viewing. The recent Flash-bashing, my desire to reach iHandhelds and my preference for open versus proprietary means that I want to make the move to HTML5 techniques this year. In the long-term, I think the writing's on the wall for Adobe's product, and I'm not entirely convinced that's a bad thing.
I'm relatively comfortably with both CSS and HTML, having worked a little in web design before. However, JavaScript is a foreign country to me, and I simply wanted to get some advice as to
whether what I want to achieve can be accomplished consistently across all browsers and
what the best techniques/approaches to the problem would be.
Any advice, even general principles, are very welcome. I've already sought out several HTML5 tutorials and introductions, which lead me to believe that the canvas element will be foundational to my plan; however while all the individual problems I face have been answered by many blogposts and guides, combining the various solutions into a single entity is something I'm not currently able to figure out, as I'm not certain of the limitations of the new HTML5 tags, or of best practice.
If I'm successful in achieving what I'm after, I'm going to post the full code online with an explanation of all the elements. Webcomics might not be a huge domain, but having a resource that did this would have made my life a lot easier - hopefully it'll help someone else in a similar position.
What I'm after
Here's a diagram giving the basics of the design requirements. I'll explain the elements, and the desired extras, below.
(Perhaps the simplest way to demonstrate what I'm after would be for interested folks head over to my website and see how my comic currently works. This isn't a plug - it would simply give the quickest insight.)
At core, I'm after a viewer that will:
display text (SVG image) in a canvas element above an raster image the page's panel art
both images should be zoom-and-draggable in sync but should ideally fade in separately, with the raster image coming first, followed by the SVG image
I'm guessing that the best way to accomplish this would be to layer two canvas elements one above the other using z-index, with the SVG file in the uppermost element. These could then be nested, as in the diagram, within a div element that would carry the zoom-drag function. Is this a reasonable approach, or are there more efficient options?
The next and previous buttons are self-explanatory. Would it best to have each page (bearing in mind some will involve animation and music) on a separate page, or to have all pages within a chapter on a single page, with the buttons making them visible progressively? I imagine this would have a great impact on loading speeds.
Finally, I'd like to have the viewer capable of displaying fullscreen if the reader desires. I imagine this could be accomplished by using Javascript to make the canvas elements and their surrounding div switch between different CSS giving a px-defined size and 100% height and width. Is this a good approach? Is it possible to apply the size change to the div element only and have the canvas elements automatically follow suit, possibly by defining their size via % in CSS?
Desired extras
At various points in the comic I make use of basic animation techniques - simple movements of layered raster images across the viewing pane. This would be simple to accomplish, I imagine, using Javascript; am I correct in thinking that applying overflow:hidden to the wrapping div will prevent images larger than the viewing area from spilling outside the viewer area?
I also want to synchronise audio with some of these animations. I understand that synchronising canvas events with the audio would be the best way to do this on, permitting both to begin activity only upon page loading or next button click.
That's about everything. As said, any advice at whatever level would be greatly appreciated, even if it's 'yes' or 'no' to the various questions I've asked. At root, it would also be good to know if HTML5 is the best option for what I'm after or whether (with gritted teeth) I should stick to Flash for now and go after handhelds using Adobe AIR.
On a website I'm creating, I have about 100 various thumbnails (64x64) that get displayed at different times. On some pages, only 5-15 thumbnails may be displayed. On others, all 100 are loaded.
I'm considering using a technique like CSS sprites to display the images. That is, rather than have image tags for each thumb, do something like:
<span class=thumb1"></span>
And then use CSS to take a slice of one single image with all the thumbs stitched together. That is, one image with all 100 thumbs (in this scenario, a 640x640 image).
My questions:
Is this a good idea?
If yes,
should I do it on all pages the
images occur, or only on the pages
with all the images?
Is there
another technique other than sprites
that may be better than simply
including the images with img tags?
If you think that an ordinary user would visit at least two different pages with these thumbnails than my opinion is that using sprites would really be a good idea!
I would in fact make a single big image with all the thumbnails and then use it in all the pages!
Why?
Fewer http requests (from 100 to 1)! And this is one of the most important thing about web site optimizations (read here from Yahoo Performance Team speed optimization rules )
This way users will download the whole image only the first time and then they will get a super quick loading of that images in all the following pages
The most famous websites on the internet already do that! See sprites used in Yahoo, Amazon or Youtube pages.
You can add other UI or layout images to your sprite
Optimize the resulting PNG:
After you have generated your sprite, if a PNG, you can optimize the PNG even more using this tool: http://www.sitepoint.com/blogs/2009/09/18/squishing-the-last-drops-from-your-pngs/
When not to use sprites:
When part of the images in the sprite change frequently
In this specific case: when the majority of users would need less than the (about) 10% of the images
I'm not quite sure what you mean with "sprites", but this is what I think you mean: instead of 100 images seperately, you create 1 image, with a 10x10 raster. Each coordinate (x,y) contains one of the images you like to show.
Now, if you display an image, you use CSS to set background-location: i.e. x * -64px and y * -64px, perhaps using JavaScript to calculate the x and y for each image-span, or Server-Side scripting to print out a dynamic CSS.
Yes, this is a good idea: it reduces load time, since one only has to download one big image, instead of hundreds of smaller ones.
It depends. If you have caching-abilities for a page, then you can "stitch" all thumbnails into one image file. If you have a very dynamic webpage, then it's quite harsh to build this stitched image every time the thumbnales are updated.
Not sure, if this is what you ment with "sprites", then no, if you ment something else with "sprites", then yes: this answer is an example of one.
It is a good idea if
Speed matters
You don't care about accessibility (screen readers reading the ALT text of an image, etc, all that is gone when you use sprites)
You don't care that your thumbnails are not going to be printed by default in any browser
You can do it without it becoming a maintenance nightmare (which image was on position 461 again?)
As to your second question, it is probably advisable to put all sprites into one or very few container images to minimize loading times.