I uploaded a PNG image with alpha transparency to my server with the filename logo.png, however, when the image is used on a page and I go to see it's file-path, I get:
http://example.com/i/300x300xlogo.png.pagespeed.ic.0A66xVq4G9.png
That file is nowhere to be seen on the server.
I don't know if it affects it, but the actual image size is 400px by 400px, and I have it displayed in the HTML as 300px by 300px. (Don't ask.)
Could it be my web-host doing this? Seems to prefix the file with the resolution to be displayed at: 300x300x and also has that weird suffix: .pagespeed.ic.0A66xVq4G9.png
The URL you're seeing is as intended: mod_pagespeed rewrites the image URL to an optimized name and embeds the size, as well as the fingerprint of the content into the filename.
If you're downscaling the image in HTML from the original size.. you're wasting user's bandwidth, which is especially painful on mobile. Advantage of mod_pagespeed is that it can do this resizing for you on the fly - simply specify the desired dimensions in the HTML and it will do the right thing.
You can read more about the various image optimizations done by mod_pagespeed here:
https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize
What you're describing as "loading slower" sounds like "image lazyload":
https://developers.google.com/speed/docs/mod_pagespeed/filter-lazyload-images
The images are deferred until onload fires, which helps get the page painted faster to the screen. You can also configure mod_pagespeed to do this on-scroll, such that only visible images are loaded. Finally, you can also disable this specific filter, but keep the image optimization done above.
P.S. mod_pagespeed is no longer beta, the team recently shipped 1.0.
Solved! Google Pagespeed was enabled by default in the webhosts control panel. Hopefully this will help anyone else.
I noticed that images would actually load slower, they would flash once the document finished loading. (Google Pagespeed is beta though.)
Related
All-right..
A couple of minutes ago I was pulling my hair out over this, but I think I narrowed down the problem.
In my html-page I want to use the image from this URL:
https://vignette.wikia.nocookie.net/mrmen/images/d/d2/Mrtallimage.png
Following the URL we see, that the image is 354px x 864px
However, as seen in the following Fiddle, when referring to the image in an img-tag, it is 200px x 488px
(But the right size, if you download the image, upload to Imgur, and the reference it..)
https://jsfiddle.net/hync8ovs/9/
So it has to be something server-side at
https://vignette.wikia.nocookie.net that resizes the image, when
it's being used as src in an img-tag, right? Is that even possible? And is it possible to "force" the original size?
I'm pretty sure, I've never come across this problem before..
Thanks!
(Disclaimer: I was only using the image for testing purposes in my web-app, that takes an image-url and analyzes the image. It was acting weird with this image and I was just wondering why.)
So it has to be something server-side at https://vignette.wikia.nocookie.net that resizes the image, when it's being used as src in an img-tag, right? Is that even possible? And is it possible to "force" the original size?
I believe the server at vignette.wikia.nocookie.net checks the referrer url, and then sends the smaller image when it is not directly (or perhaps via the same domain) requested.
That's %{HTTP_REFERER} doing this.
Read about it at https://httpd.apache.org/docs/2.4/rewrite/access.html
If it's only happening within JSFiddle it's likely a compression/resize being done by their service. The reference to the image is no different in any of the other locations. If it were being resized by the vignette.wikia.nocookie.net location when you pull it up in another window it should still be resized to 200 x 488. I don't think it's anything you're doing.
Anyone know if adding a tracking pixel (just a transparent GIF with some logging going on at the server that's sending out the GIF) as a background-image in a linked stylesheet will work the same as if it was a regular <img> on a page?
From a simple test I did in Chrome's network inspector it looks like it's just pulling images from local cache if I go into the location bar and hit enter. If I actually click Reload then I see it go out to the server and get back a 304. And if I shift+reload it'll force it to go back to the server for real and I get 200s.
But, it looks like it's the same behavior for the <img> images on the page as well, so then the behavior as a background-image should match the behavior as if it was an <img>
It should work exactly the same way. But tracking pixels are not decorative, or are specific to a single page, so it is easier to put an img tag in the HTML and a little more reliable, it will work for text browsers, etc.
Having a tracking pixel called via CSS would be possible, but there would be some challenges compared to using a tracking pixel in HTML:
Tracking pixels commonly have visitor data detected by JavaScript (monitor size, for instance) added to the pixel's URL. JavaScript would be unable to (easily) do this if the pixel was called via stylesheet.
When in the page source, the tracking pixel can be at the bottom of the page and be modified by code that executes first. This would be difficult to do in a single-pixel-call via CSS.
I just started using the chrome developer tools for some basic html websites and I used the audit tool.
I had two identical images, one with the height and width attribute, and one without. On the Resources section, both the latency and the download time were identical. However, the Audit showed
Specify image dimensions (1)
A width and height should be specified for all images in order to speed up page display.
Does this actually help? And are there any other ways to speed up page time?
This is only a splash page for the website I am building and as such it is only html, no css or javascript or anything. I have already compressed the images but I want to speed up load time even more. Is there a way?
Generally speaking: If you specify the image dimensions in the <img> tag, the browser will know how much space to allot for it and will proceed to render the rest of the page while simultaneously downloading the image. Otherwise, the browser will have to wait a few more milliseconds to get the size of the image from the image itself before rendering the rest of the page.
Since you have only a splash page, I doubt that there will be anything else for the browser to render, so it doesn't much matter whether you specify dimensions or not.
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.