All discussion about favicons recommend creating favicons of different sizes to target different clients. See this answer for example: Does a favicon have to be 32x32 or 16x16?
My question: Is it really necessary to generate favicons with so many different size? What if I created one large favicon of size 200x200? I see various browsers like Chrome and Firefox automatically scaling it down to display a pretty scaled-down favicon in the browser tab.
What's the problem in going for one large favicon of size 200x200 then?
Note: I want the favicon to work on any device browser that conforms to the standard (if there is one for favicon). For example, if iOS Safari violates the standard then I am not too bothered with supporting it.
There is no problem with using one large high-resolution icon (in 2017). Browsers and mobile devices with smaller screens made in the last 4 years will automatically scale them down attractively (if not perfectly) as needed.
The only downside I can find for using one large favicon—and it's a stretch—is that mobile devices with lower resolution screens will download a slightly larger file than is absolutely necessary. We're talking kilobytes here.
File Size/Loading Time:
Even on a 3G connection, the time it takes to download a single 5kb favicon vs a 100kb favicon is negligible. Unless your 200x200 favicon has a much larger file size than the lower resolution versions, it's perfectly okay to just create one high-resolution favicon file and use that for all browsers/devices.
This isn't really even a load time issue, because in most cases the favicon would only be downloaded on a mobile browser when it's bookmarked rather than loading with the rest of the page.
iOS Safari/Android Chrome:
I've never personally experienced any issues using a single large
favicon image in PNG format. You'd still want to include the
Apple Touch Icon code (<link rel="apple-touch-icon"
href="/custom_icon.png">) in addition to the normal favicon code,
but you can use the same favicon image file.
This look at how iOS Safari scales down icons seems to agree that dropping the smaller icon file sizes is completely fine if 100.0% pixel perfection is not needed.
I've seen it pointed out on a number of sites (caveat: in threads
that are a few years old) that Apple themselves use one large
152x152 favicon for apple.com. The file size is 4.5kb.
Although Apple uses 152x152 for their Apple Touch Icon, I'd recommend going with a 192x192 favicon image because this resolution is used by Android Chrome.
TL;DR:
As far as I can tell, yes, one large size favicon can work on all modern devices and browsers that conform to standards. The difference in favicon file size of a few kilobytes is mostly irrelevant today, thus I cannot find any problems with this approach.
The question you referred is 3 years old and nowadays I'd (and I usually am) create one, high res favicon and assume browsers would (and from my experience it will) scale it down if needed.
Some browsers could scale it down; however, IOS currently doesn't support favicons, so it would be completely useless to make one for it. Unless you want to add it into your text file whenever Apple does build the support for it.
I would recommend going with a 16x16px size, since it has less memory attached to it.
Related
I have too many png images in my website. How can I load my website fast? I have minified html css and js files, but it still doesn't work. :(
Convert to jpeg, if it is feasible. Jpeg is not lossless, so the quality will worsen, but on pictures having many transitions and only a few sharp edges (i.e. photos) it is practically invisible.
Optimize the pngs. There are many png optimizing software on the market.
Finetune the cache headers on the server side. It is possible that your web server doesn't sends valid caching headers and thus forces the browser to reload the images again and again.
Finetune your html and css. It helps a lot, if the browser knows the size of the png (from the css) before it would be even loaded.
Analyze your traffic. Where is the weak point? Does it need to load too many traffic (so your page is too big), or the browsers need to many cpu cycles to render them? Check with some tools (there are also a lot of on the market), what is your browser doing while loading your page. You could even see this in a windows task manager. Does it use 99% cpu, or much fewer?
You could convert them over to WebP images (which can be up to 3x smaller than PNGs).
Now that the new Macbook Pro is coming out with a Retina Display, there are a lot of resources out there on how to make Mac apps and now even websites "Retina Display Friendly". Even Google is updating Chrome for Retina Display...
Why is this necessary at all? From what I understand, Retina Display is just a higher resolution screen. Right?
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly.
So why are these people coming out with guides on how to make something look good on a Retina Display? Shouldn't it already look fine by default? Is there something about Retina Display that I'm not understanding?
And for the record, I'm not talking about iPhone 4 Retina Display. Most iOS dev's make their apps with fixed position elements since they know the screen's won't change size/shape. So I understand the importance of developing an app to look good on the iPhone 4/s vs 3g/s.
With the Retina display apps don't actually scale like they're being resized, all the controls are resized to be twice as big. If an app would be scaled normally, not by scaling all the controls, etc. you wouldn't see anything, because everything would be too small. It's the same difference between a Retina and a lower-resolution display as on the iPhone 3GS / iPhone 4.
An example:
These images are actually the same size, just the pixel densities differ.
And here's how it looks not properly scaled (using some app to disable proper scaling):
http://cloudmancer.com/images/trueretina.jpg
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly (StackOverflow, for example, uses a 960px-wide container).
From a web developer standpoint, you are often asked to develop fixed-width websites (ranging from normally 940 to 1000 pixels wide), and they don't get to scale at all. There are a lot of websites like this and many apps just aren't designed to increase in size.
Also, apps that do grow in size usually expect that a bigger resolution also means a bigger screen, so they simply stretch the main application panels and are done with it.
Now, consider static elements, like a 150x50 button that says 'Click me'. This button is not intended to become bigger and is perfectly acceptable on a regular 1440x900 display. Now the retina screen comes in with its 2580x1800 resolution. The app sees the resolution change but it thinks "Hey, that user must have a huge screen" so it keeps the button the same size.
The problem that now occurs is that the button, because both resolutions apply to the same 13" screen, is now appearing to be a fraction of the size of the original button. Depending on your user vision, he might not be able to read the text on it, and might have a hard time clicking it, depending on the mouse settings.
To fix that problem, Apple and Microsoft used two different solutions:
Microsoft decided to tell the app the display had a 2580x1800 resolutions, but that the user wanted to have everything scaled to 200 dpi. This means that, if an app does not follow the guidelines, it will look smaller. Many apps simply ignore the DPI settings (though this might change with Windows 8);
Apple decided to report to apps that the resolution of the monitor was 1440x900, but that it could display higher-resolution elements if asked to; This means that apps existing before the new retina settings will appear to be the same size as before for the end-user (with added benefits like crisper text if they use the default Apple APIs), but that they can decide to provide high-DPI images that will look much better on the display.
Both solutions requires apps to be aware that the display is high-DPI ('retina'), but the way Apple handled it means the static websites and apps mentioned earlier will keep looking just fine, except they wont have super-crisp, high-resolution images to use. And, to opt-in to the retina features, they have to provide 200x200 images for a 100x100 canvas, for example, and Apple will take care of the rest.
I'm working especially with Java web applications (in which mostly with JSF, Java Server Faces). I'm less concerned with the rest of the technologies.
Since different web browsers function less or more differently from one another, any web application should be designed in such a way that it can be incorporated and executed in a defined way by most browsers (might not be all). Which points should be kept in mind to design a web application in such a way that it can function almost exactly on most browsers?
What are the major differences among different browsers which should be noted by web application developers?
you have to check all of these points befor developing web applications with any language...
Almost all web developers (ahem! – perhaps that should read “quite a lot of web developers”) are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be:
Firefox, as that has the best standards compliance and is the second most-used browser;
Internet Explorer for Windows – currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7
fixed quite a lot of bugs in 6 but introduced a new set of its own.
(Microsoft is however still kicking developers in the teeth by not
making it possible to install both versions on the same computer; you
will either need two computers or one of the work-arounds available
on the net.) Version 5 should preferably also be checked; as of
spring 2008 the number of users is not yet negligible. However it is
now uncommon enough that you needn’t worry about cosmetic issues; as
long as the site is readable that should be sufficient.
Opera – growing in popularity due to its speed and pretty good standards compliance.
For some time I also recommended checking Netscape 4 as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now so small (under 0.1% and decreasing) that it can now probably safely be ignored.
Check printed pages
Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably can’t achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page. It is truly extraordinary how many site authors fail to think of this most elementary of operations.
You should also consider using CSS to adjust the appearance of the page when printed. For example you could – probably should – suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the “#media print” or “#import print” CSS features.
Some sites provide separate “printer friendly” versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldn’t usually be needed.
Switch Javascript off
There are unfortunately quite a number of Internet sites which abuse Javascript by, for example, generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off – indeed I often do myself. (I have a page giving the reasons in more detail.) Some organisations even block the usage of Javascript completely. Furthermore few, if any, search engines support Javascript.
It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely – quite unnecessarily – on Javascript for navigation, with the result that the lack of Javascript renders the site unusable.
Clearly if you need it for essential content, that functionality will be lost. But there is no reason why the basic text of the site should be unavailable.
Avoid nearly-meaningless messages like “Javascript needed to view this site”. If you have something worth showing, tell the user what it is, e.g. “enable Javascript to see animation of solar system”.
Switch plug-ins off
The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript above. Check the site with any plug-ins disabled. The basic text and navigation should still work.
Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a “You need Flash to read this site” message and he will probably go away, never to return.
Switch images off
If scanning a number of sites quickly for information, many readers (including myself) switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This means, in particular, checking that sensible ALT texts have been provided for images. (This check is similar to using a text browser, but not quite the same).
its worth to take a look at this link for more info
I am having a little issue here. I am a web development major and I am currently building this site for a project I am required to do. I wanted to make it look pretty with a background image. I created the image in Photoshop and saved it to web as a .jpg and it ended up being 58.8k in size.
I am all for websites that load quick for the user, but I am wondering if less than 60k is okay? I checked it on the yslow firefox extension and it loads for me in 96 ms (slightly poor test subject - http://www.speedtest.net/result/1146275377.png)
Is 60k too much, is it a best practice to have images only 10-20k? I HATE it when I see an image loading... it just.. isn't even worth the graphic at that point. Is there quicker ways to load a image of that size? CSS or tag? Or should I not even be worrying about it?
Most browsers load the background image last by default, so you shouldn't have a problem.
How large is too large depends on your hosting set up, the amount of traffic your site gets, and the typical transfer rate of your visitors.
60k seems reasonable to me for an average site with not too many simultaneous visitors. However, bandwidth costs money and this is the reason that you rarely see background images of that size on big sites. On the other hand, youtube regularly streams videos that are thousands of times larger than the background image that you propose. It's impossible to give you precise advice without knowing much more about your site, its hosting solution and it's usage statistics.
Chances are, if you're asking this question, 60k is perfectly fine.
If you want to guarantee that your background image loads first or last you can do:
<script type="text/javascript">
bgimage = new Image();
bgimage.src = "http://www.olhovsky.com/img/cdf97/256fwt1_eg.png";
</script>
Place that code above the body tag to preload the background image. Place it lower in your html document to load it later (e.g. after the </body> tag to load the background last).
And then in the body tag:
<body onload="document.body.background=bgimage.src;">
I don't think 60k is too large although you probably want to look at your likely users and think about what their connection speeds will be like. If you wanted to try and squeeze the file size down as much as possible, try smushing it as well and you might see it drop a little further.
This question already has answers here:
Closed 13 years ago.
Duplicate:
Recommended website resolution (width and height)?
I tend to think of 1024x768 as the minimum Screen Resolution that a modern web browser will run in, but I worry when using this resolution for a business website because I feel that I might be hurting the folks out there who are stuck with something smaller/older. So I ask, realistically, what is the minimum screen resolution I should expect my website to function perfectly in with the browser "maximized"?
Look to the Netbooks for a new minimum. I'd say 1024x600 is reasonable.
Edit: You can always look to any number of sites that give you statistics on browser usage. Here's one that Google turned up for me:
http://www.w3schools.com/browsers/browsers_display.asp
From an article in Jacob's Nielsen Alertbox called Screen Resolution and Page Layout:
Optimize Web pages for 1024x768, but
use a liquid layout that stretches
well for any resolution, from 800x600
to 1280x1024.
Depends on your audience. If it's mainly American consumers at home, then I think you're safe with 1024x768. For schools, corporate and global international audiences you'll want 800x600 because schools and businesses are less likely to have upgraded computers, and international audiences in various countries may not have larger screens available for whatever reason.
Can I also suggest you test a maximum resolution as well. Many sites are unusable (without zooming) at 1920x1200 due to people using fixed font sizes and the like.
Dear God, have we forgotten?
The WHOLE POINT of HTML - a LOGICAL page description language - is that you NEVER have to think or worry about the display device.
What happens if the display device is a text-reader for the blind?
Or a text-only browser on a console?
But that's not the main point; the main point is that HTML LOGICALLY describes the page. If you in your logical description of the page are making PURELY PHYSICAL descriptions then you GOT IT WRONG. You're writing web-pages like you're Word emitting HTML!
You need to write your web-site so it works LOGICALLY - which is to say, you leave the problem of rendering PURELY in the hands of the rendering agent. If you're not doing that, you've got it WRONG.
Consider using a fluid layout that adapts to the user's screen. Most sites with a fixed layout force the majority of users to view the site targeted to the least common denominator even though 90% of the visitors have a much higher resolution available. This results in layouts that are overly populated with navigational chrome and little content.
If you must use a fixed layout, consider taking a cue from MSN where you split the screen into 760 and 224 pixel columns. If the visitor has a resolution of 800 (which you can detect in JavaScript) then hide the 224 pixel column.
UPDATE from comments: As for determining a safe min though I'd set your screen to 800x600 then browse some of the popular general public sites - MSN, Yahoo, etc. and see what they do. It's a good bet they've invested a lot of research in this area and adopting what they've done is usually a safe bet
1024x768 is fine. Most people have that resolution setting and the ones who don't won't have a heavily compromised user experience. Also, to ensure your page fits nicely into the browser, taking into account scroll-bars and such, make the with of your pages 960px.
1) My browser is not maximized. The size of my screen doesn't matter. The size of my browser window does.
2) The iPhone's screen resolution is 480x320. NewEgg currently lists at least one 1920x1080 monitor for under $200. Designing to either of those resolutions will make your site completely unusable on the other. Even if you split the difference and design to 1024x768, you'll get a stripe covering half the screen width on the $200 monitor (which, IMO, looks like crap) and it will still be completely unusable on the iPhone.
Screens aren't just getting bigger. They're also getting smaller. The trend is moving to fluid layout instead of fixed-width and it's for a damn good reason.
I usually design websites 800 wide.
Height isn't a problem, as the user can scroll.
As Mark said, there are a number of netbooks around now.
Most of them now have the 1024x600 size, but there are also some of the "older" netbooks that have lower resolution then that still. Mine for example has *wince* 800x480.
If you want to be really compatible, go for 800, but otherwise, I'd say your good with 1024, and as for the height, the user can always scroll.
Don't forget that scrollbars, toolbars, and sidebars can constrict the space a little. Even if you assume the resolution is at least 1024*768, don't make your page 1024 wide.
Definitely 1024 wide (as in 980px or so usable), but please don't design for a fixed height.
I'd take a look at those statistics: http://www.w3schools.com/browsers/browsers_display.asp.
As of January 2009, only 4% of people visiting W3Schools are using 800x600 as resolution. The remaining, are using at least 1024x768.
Beware of how much of that 4% could be part of you users, though.