I have a messy background on my site and, to make it a little easier to read I use this background property:
p : background-color {rgba(250, 250, 250, 0.7)}
With the goal of site load time in mind, would it be better to use a background image with opacity?
You can see the issue here: http://tinyurl.com/7ywoqpf
Note I am already working on reducing the background PNG size, this question is about the paragraph background only
Should I keep current settings or use a background image?
Images have to be downloaded from the server then loaded to browser, Where as using CSS properties like rgba to create the effect, It relies on the browser alone. So without a doubt, rgba is better than images.
Ok this is what the page load waterfall looks like - http://www.webpagetest.org/result/120505_MG_47R9V/1/details/
You already know you need to reduce the images but there's a few other things you can do..
Remove duplicate ga.js
Use jquery.min.js instead of jquery.js
Turn on gzip for html, css and js
If you're looking for an image compressor jpegmini.com does a fine job with jpegs, and there are plent of options for PNGs
Images, no matter how well compressed, always have to be downloaded. There will always be some overhead to that thanks to ping. What's more, because many browsers insist on never making two simultaneous requests per hostname (behaviour defined in the HTTP spec), any images will always defer the loading of other resources.
I don't know about the implementation of RGBA, but I would be very surprised if it meant downloading another resource was faster.
Related
I need to implement image previews via thumbnails. Now I'm not certain how to implement it.
One option would be to do it straight with CSS, so something like this:
.thumbnail {
background-image: url(path/to/image);
background-size: 300px, 400px;
}
Is that practical? Are there any performance issues?
If you scale image in CSS to be smaller than it it actually is, browser still have to download the same amount of data. You should create separate file with the thumbnail.
With images, you need to focus on three things: size, format and the src attribute.
Image size
Oversized images take longer to load, so it’s important that you keep your images as small as possible. Use image editing tools to:
Crop your images to the correct size. For instance, if your page is 570px wide, resize the image to that width. Don’t just upload a 2000px-wide image and set the width parameter (width=”570”). This slows your page load time and creates a bad user experience.
Reduce color depth to the lowest acceptable level.
Remove image comments.
Image format
JPEG is your best option.
PNG is also good, though older browsers may not fully support it.
GIFs should only be used for small or simple graphics (less than 10×10 pixels, or a color palette of 3 or fewer colors) and for animated images.
Do not use BMPs or TIFFs.
Src attribute
Once you’ve got the size and format right, make sure the code is right too. In particular, avoid empty image src codes.
In HTML, the code for an image includes this:
When there’s no source in the quotation marks, the browser makes a request to the directory of the page or to the actual page itself. This can add unnecessary traffic to your servers and even corrupt user data.
Pro Tip: Take time to re-size your images before uploading them. And always include the src attribute with a valid URL.
To ensure your images load quickly, consider adding the WP Smush.it plugin to your website.
from: http://blog.crazyegg.com/2013/12/11/speed-up-your-website/
I'm trying to create a gallery for a mobile site where I have different stylesheets for different sized devices. Within these stylesheets I have several classes which simply set a background url property to each image I want in the gallery.
Only one of these will be displayed at a time. And I will be cycling through the classes using Javascript to display them in a slideshow type presentation.
I am wondering is this method more bandwidth efficient than having all the images as individual img tags within the DOM? By setting these url properties do they get downloaded to the user's browser when they first load the site or are they only downloaded when the class gets set on a div in the DOM?
Simply I am trying to avoid having to download all the different images to the user's device at once. If you know any alternate methods which are better for this sort of thing I am also interested.
You are right, When you set the image backround, the image will only be downloaded if it is used, By this I mean, used as a style on some dom element.
Alternatively, you could 'change' the background-image css property using javascript. This way, you don't even have the image url in your CSS.
If bandwidth is your biggest concern, I would urge you to have a look at the inspector in webkit browsers like Chrome or safari, or with firebug on Firefox to see the 'network' tab, there you have a clear overview of what is loaded, how ( what order ) and how to optimize things. You can also make some stupid mistakes clear like downloading multiple times the same library from different locations and so.
If you just declare the class in css it shouldn't download anything before it is set. however it is a round question and the answer could take a lot of different shapes.
So I would say that yes it is a good way to do it, and it should be more bandwidth efficient (if you don't know that all the images will be loaded eventually anyhow, since you will typically have asynchronous image-loading either way it shouldn't matter much. I guess that if you only load one image initially the other images (i.e. the mentioned img tags) will not interfere making the load a bit more smooth?).
I find it to be a cleaner solution at least if you aren't sure which images will be viewed (which is likely to believe) to use your css-approach. also it's easier to maintain and provide a better design.
That you will be using javascript indicate that you are also doing the client side. And that give you control to choose what to do which is great :)
One alternative could be to have a local cache of the images as well, but that really depends on the problem at hand, if you will have different images and no real possibility to know in advance which images you will need (and perhaps not even how many of them?) then I think that the cleanest way is the way you purpose.
i.e. set up (or dynamically create) css-classes for images and handle all the logic in javascript.
I tended to put plain color in a big div (960x1250 px) with dashed border. So, I have 2 solutions I applied:
Use background-color and border: CSS tag
Use static PNG-8 image
I have tested both of them but I could not really see the different. Do anybody experiment the performance of web browser when using tag background-color versus static picture?
Thanks for your advance answer.
The only probable difference is in the time it takes the browser to fetch the image. Compared to that, the rendering time is negligible.
When you test, make sure the image is fetched remotely, not from the browser cache. When fetched remotely, I predict the image option will be much slower.
You should prefer the first solution.
A few bytes of CSS compared to many kilobytes of image data (even if the image is small and repeated) is nothing for loading and caching on client side. On slow (mobile) systems it's even better to use CSS because it's rendered even faster then an image. It's even important for accessibility to use CSS instead of static images but the major effort is, that this is faster for both loading and processing.
I'm working on a website that's already been designed by someone else. The designer has used a big image (900x700 100KB) which contains a big logo right across the top, then the background for two columns.
This image loads every time a page is loaded as it forms the basis for the website. What should I do with it to improve loading time?
I'm considering splitting it up into two or more images, especially the logo on the top. Does splitting up images like that decrease loading time in any significant way?
Thanks
-edit: Also, all the images are .jpg, would changing this to .gif or .png help anything?
Things to try:
Repeating backgrounds: If part of it can be broken off into a repeating image, you can reduce file size a lot that way (divide the image into the parts that don't repeat, such as a logo, and the parts that do, and then use CSS to repeat it as a background).
Caching: You should look into whether the image is properly being cached or not. There's no reason it should reload on every page request. If the HTTP headers correctly allow caching, then the browser will not request it again until the image is cleared from its cache.
See http://www.mnot.net/cache_docs/ for some info about cache control with HTTP headers.
Use the Web Developer toolbar for Firefox to check the headers for the image (hit the image URL, then click Information > View Response Headers)
File quality or type: Also, you may be able to use Photoshop to resave the image in either a different format or lower quality. GIF and JPG images can have greatly different file sizes for the same image depending on the content of the image (GIF is very good for graphics with limited and/or repeating colors, especially when large portions of the same color run in consecutive horizontal pixels). If the image is photo-like, JPG can be very good because high compression can be disguised in very detailed images.
Crunching (removing unnecessary metadata and finding a more efficient compression algorithm) the image with a decent image compressor is a good start. Reducing the number of colors, changing the format (GIF or PNG24 to PNG8) when possible.
This may be totally obvious, but... defer it until the page is fully loaded (if the contrast of colors in the background image are not needed to make the foreground text readable).
An easy way to do this is to make the css selector for the background image dependant upon a class in the body like:
...
<style type="text/css">
/*<![CDATA[*/
body.page-loaded{background:url(/path/to/image.jpg)}
/*]]>*/
</style>
</head>
<body class="page-loaded" onload="document.body.className+=' page-loaded';">
...
Of course, the "onload" attribute in the body tag should be migrated out (to a SCRIPT tag at the bottom of the page or in an external JavaScript file). Also this code doesn't require any JS library to run; it should probably make use of an event observer.
The two things you want to do are:
Convert it to PNG (10-30% smaller than GIF on average); and
Cache it effectively.
The way to cache it is to version it and use a far future Expires header. For versioning I generally just use the mtime (last modified time) of the file as a query string:
body { background-image: url(/images/background.png?1232343455); }
See Speed Tips: Add Future Expires Headers for adding the Expires header. You can do it with a script or with Web server configuration. The reason you need the version is that you can change it to force a reload of the file otherwise you need to rename it whenever you want to change it.
This way the background will only get downloaded once. Splitting the file into several will actually worsen the situation as browsers tend to limit the number of concurrent downloads and you'll be downloading more data overall (more HTTP headers plus image file overhead).
Putting the image on a CDN may also help (along with the other things mentioned), because people may load images from the CDN faster than your server.
We are working on a website and noticed that the GIF images(100kb - 200kb) are loading very slowly.
The site is a static site with CSS/HTML.
Does any one have any pointers to why the images might be loading slowly?
Would using JPGs improve the performance?
Here is the HTML code for that image:
<div><img src="images/mainImg_3.gif">
They're loading slow because they're huge. 200KB is a very big image file. I don't know exactly what the going recommendation is for web images, but it's a very good idea to keep them under 50K.
GIF images are not very efficient for photographic images. You should experiment with other formats like JPG and PNG to see if you can get the same quality with smaller file size. You should be able to shrink the file size quite a bit while retaining the quality.
Another trick: use thumbnails. Save two version of each image, one 25% the size (by resolution) of the other. Your site visitors can click the thumbnail if they want to see more. This will speed loading times and reduce your bandwidth bill.
Are your images properly sized? If you displaying them on your webpage as 300x300 pixels make sure the original image is the same size.
This helps two-fold, one its less data to download, and 2 it doesn't require extra processing power for the browser to resize. Additionally, the image will look crisper if its the exact size.
As far as the difference between GIF and JPG, (with the exception of transparency, which JPG doesn't support), it boils down to what your image contains. GIF uses a color table and a map to that color table to store the image, while JPG uses a compression algorith. So, if you image contains few color variation you will get a smaller filesize from a GIF. Conversly, if you have a photograph with lots of color variation you'll want to use a JPG.
Also take a look at YSlow
It will analyze your site for you and tell you where the bottlenecks might be.
Enable caching for image files (the example below also adds css and js caching) which will ensure users don't download files twice. If you are using apache 1.3 or 2:
ExpiresActive On
<FilesMatch "\.(ico|gif|jpe?g|png|js|css)$">
ExpiresDefault "access plus 1 year"
</FilesMatch>
It is probably a reasonable idea to enable gzip compression for html and css. In apache 2:
SetOutputFilter DEFLATE
and in apache 1.3:
mod_gzip_on Yes
It depends on how large the image is, if you're displaying wallpaper-sized images at 100kb, that's not too bad. If you're displaying thumbnails of this size, then you have a problem.
JPEG images are lossy but can be compressed with ease. Depending on how much compression you select, you can really decrease image sizes with JPEG.
You should specify the height and width attributes for the img tag, see below for the W3C Schools explanation of why you should do this. And for further info see http://www.codinghorror.com/blog/archives/000807.html for further more radical techniques.
Tip: It is a good practice to specify
both the height and width attributes
for an image. If these attributes are
set, the space required for the image
is reserved when the page is loaded.
However, without these attributes, the
browser does not know the size of the
image, and cannot reserve the
appropriate space to it. The effect
will be that the page layout will
change during loading (while the
images load).
Tip: Do not rescale images with the
height and width attributes!
Downsizing a large image with the
height and width attributes forces a
user to download the large image (even
if it looks small on the page). The
correct method is to rescale the image
with a program, before using it on a
page.
This is copied from http://www.w3schools.com/tags/att_img_height.asp
The fastest loaded resource is always the resource that doesn't need to be loaded at all. I.e. apart from shrinking your images to reasonable sizes you should read about HTTP caching.
You should instruct your web server to deliver the responses with proper caching informations so that user agents may reuse local cached versions.
Mark Nottingham wrote a tutorial about HTTP caching. It's a good starting point.
And this is a tutorial about apache configuration on HTTP chaching.
Look into the free tool: Smush It!
It's co-developed by Stoyan Stephanov, Nicole Sullivan (of Yahoo!) and incorporates every tidbit for images from YSlow (from Yahoo!) and the Yahoo Developer Network findings.
It will analyze your image(s) and determine from a set of server side tools what the optimal image type is (e.g. PNG8, PNG24, GIF, JPG, etc.) and also create the optimized image... e.g. even if you feed it a PNG image, it will find the best method to compress it, and "Smush It" to its smallest possible file size.
Then take the output image, and then serve it up from a (cookie-less domain) if you can, preferably on a CDN, with far-future expires headers, with gzip compression.