I think it's an encoded image in the CSS but why would they do that? Does it save space is it to stop people from stealing the images?
background:url(data:image/gif;base64,R0lGODlhEAAQAPQAACNBZ7TL5CpIbWV/nzNQdIukwW2Ip7TL5IGauJ630VFtjkdjhqfA2lp1lrHI4ZSsyHiRsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh/hpDcmVhdGVkIHdpdGggYWpheGxvYWQuaW5mbwAh+QQJCgAAACwAAAAAEAAQAAAFdyAgAgIJIeWoAkRCCMdBkKtIHIngyMKsErPBYbADpkSCwhDmQCBethRB6Vj4kFCkQPG4IlWDgrNRIwnO4UKBXDufzQvDMaoSDBgFb886MiQadgNABAokfCwzBA8LCg0Egl8jAggGAA1kBIA1BAYzlyILczULC2UhACH5BAkKAAAALAAAAAAQABAAAAV2ICACAmlAZTmOREEIyUEQjLKKxPHADhEvqxlgcGgkGI1DYSVAIAWMx+lwSKkICJ0QsHi9RgKBwnVTiRQQgwF4I4UFDQQEwi6/3YSGWRRmjhEETAJfIgMFCnAKM0KDV4EEEAQLiF18TAYNXDaSe3x6mjidN1s3IQAh+QQJCgAAACwAAAAAEAAQAAAFeCAgAgLZDGU5jgRECEUiCI+yioSDwDJyLKsXoHFQxBSHAoAAFBhqtMJg8DgQBgfrEsJAEAg4YhZIEiwgKtHiMBgtpg3wbUZXGO7kOb1MUKRFMysCChAoggJCIg0GC2aNe4gqQldfL4l/Ag1AXySJgn5LcoE3QXI3IQAh+QQJCgAAACwAAAAAEAAQAAAFdiAgAgLZNGU5joQhCEjxIssqEo8bC9BRjy9Ag7GILQ4QEoE0gBAEBcOpcBA0DoxSK/e8LRIHn+i1cK0IyKdg0VAoljYIg+GgnRrwVS/8IAkICyosBIQpBAMoKy9dImxPhS+GKkFrkX+TigtLlIyKXUF+NjagNiEAIfkECQoAAAAsAAAAABAAEAAABWwgIAICaRhlOY4EIgjH8R7LKhKHGwsMvb4AAy3WODBIBBKCsYA9TjuhDNDKEVSERezQEL0WrhXucRUQGuik7bFlngzqVW9LMl9XWvLdjFaJtDFqZ1cEZUB0dUgvL3dgP4WJZn4jkomWNpSTIyEAIfkECQoAAAAsAAAAABAAEAAABX4gIAICuSxlOY6CIgiD8RrEKgqGOwxwUrMlAoSwIzAGpJpgoSDAGifDY5kopBYDlEpAQBwevxfBtRIUGi8xwWkDNBCIwmC9Vq0aiQQDQuK+VgQPDXV9hCJjBwcFYU5pLwwHXQcMKSmNLQcIAExlbH8JBwttaX0ABAcNbWVbKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICSRBlOY7CIghN8zbEKsKoIjdFzZaEgUBHKChMJtRwcWpAWoWnifm6ESAMhO8lQK0EEAV3rFopIBCEcGwDKAqPh4HUrY4ICHH1dSoTFgcHUiZjBhAJB2AHDykpKAwHAwdzf19KkASIPl9cDgcnDkdtNwiMJCshACH5BAkKAAAALAAAAAAQABAAAAV3ICACAkkQZTmOAiosiyAoxCq+KPxCNVsSMRgBsiClWrLTSWFoIQZHl6pleBh6suxKMIhlvzbAwkBWfFWrBQTxNLq2RG2yhSUkDs2b63AYDAoJXAcFRwADeAkJDX0AQCsEfAQMDAIPBz0rCgcxky0JRWE1AmwpKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICKZzkqJ4nQZxLqZKv4NqNLKK2/Q4Ek4lFXChsg5ypJjs1II3gEDUSRInEGYAw6B6zM4JhrDAtEosVkLUtHA7RHaHAGJQEjsODcEg0FBAFVgkQJQ1pAwcDDw8KcFtSInwJAowCCA6RIwqZAgkPNgVpWndjdyohACH5BAkKAAAALAAAAAAQABAAAAV5ICACAimc5KieLEuUKvm2xAKLqDCfC2GaO9eL0LABWTiBYmA06W6kHgvCqEJiAIJiu3gcvgUsscHUERm+kaCxyxa+zRPk0SgJEgfIvbAdIAQLCAYlCj4DBw0IBQsMCjIqBAcPAooCBg9pKgsJLwUFOhCZKyQDA3YqIQAh+QQJCgAAACwAAAAAEAAQAAAFdSAgAgIpnOSonmxbqiThCrJKEHFbo8JxDDOZYFFb+A41E4H4OhkOipXwBElYITDAckFEOBgMQ3arkMkUBdxIUGZpEb7kaQBRlASPg0FQQHAbEEMGDSVEAA1QBhAED1E0NgwFAooCDWljaQIQCE5qMHcNhCkjIQAh+QQJCgAAACwAAAAAEAAQAAAFeSAgAgIpnOSoLgxxvqgKLEcCC65KEAByKK8cSpA4DAiHQ/DkKhGKh4ZCtCyZGo6F6iYYPAqFgYy02xkSaLEMV34tELyRYNEsCQyHlvWkGCzsPgMCEAY7Cg04Uk48LAsDhRA8MVQPEF0GAgqYYwSRlycNcWskCkApIyEAOwAAAAAAAAAAAA==);}
It is called data url and contains an image in the GIF-format in this example. It saves you an extra HTTP request, but can only be used for smaller files, since some browsers limit the size of data urls. It has downsides though: Caching does not work properly for those images. Additionally, browser support is not very good at the moment (IE7 lacks support and IE8 limits the size to 32KB).
It's to reduce HTTP requests. Personally I'm not a fan of this technique as it's more troublesome to maintain and update, and images can't download concurrently.
It's the whole contents of the gif in base64 format. It's just as easy to save the image as a file from the browser, so security is not the reason, but saving an extra HTTP request as others said.
it's basically a base64 output of that image , it used to save http requests and speed thing up
i think if you read this , you will get all needed information
When you should use base64 for images
Related
I understand that it is a risk to use SVG and Wordpress disable the use of them. But many website nowadays use SVG because of the performance and resolution. So are all these websites having a huge risk to get hacked?
If I would code the website in plain html, css, php, mysql without a cms, would my website be highly risked to get hacked too?
SVGs are effectively (XML) text that are interpreted and rendered by the browser. The SVG "text" can include scripts (for valid or malicious reasons). SVG has a lot of benefits. I use animated SVG headers that I created myself on my Wordpress sites; file are small and do not rely on JavaScript for animation.
I assume you are ONLY talking about having your OWN SVG images for the header, or in your own posts (and won't be including malicious scripts to attack you or your visitors!). If so, in my fallible opinion, there should be near Zero (can never say never) risk as long as you cater for these possibilities:
you use an SVG file created by someone else that contains malicious code. So create your own, or obtain them from one of the major image sites and check the SVG source text carefully before use.
a visitor/user uploads (innocently or otherwise) a poisoned SVG. Even if it is not displayed on your site the simple act of you viewing (say via Cpanel) the uploaded file in a browser could trigger the malicious payload. So block anyone else from uploading SVGs. Ideally upload your own via FTP and block all uploads via your site's pages.
see also https://wordpress.stackexchange.com/a/247190/128374
I have made changes recently to include base64 data uri strings in my css instead of image requests to external image files.
The issue this has caused is the increase in size from a stylesheet without data uri of 7KB to that 200KB+ with them. However I have significantly less http requests.
Is this ok - is the approach of large stylesheet better than one with multiple image requests?
Compare the size of the stylesheet to the total size of the images you base64'd. If it is the same or smaller, using the base64 URIs takes up less space (and download time). Generally, one large request is preferable over multiple smaller requests if the data being retrieved is identical and said requests are not concurrent.
200Kb is quite big for a stylesheet. Make sure you're serving it compressed if you're not already. If some/most of the data string images aren't used on most pages you might be better off splitting those into a separate stylesheet and including it only on pages where required.
How about you keep one stylesheet at the top of your document (in the head) that contains everything except for your base64 data. This will load quickly, and let the body of the document begin to load/display with these initial styles.
Then, create a second stylesheet at the bottom of the document (right before the closing /body tag) which contains the images as base64 data. That way, when this starts to load, at least the content is visible and mostly structured the way you want it.
Win-win??
Good luck!
Less requests, the better.
However, hostings limit the connection speed of a particular download stream. So, if your 200KB file can be downloaded in 2 secs, maybe 2 files of 100KB could be downloaded in 1 sec.
The rest is on you.
ADDED:
You can't gain any size reduction using compression. Your image data can't be compressed.
In the Firebug Net panel, you can get a list of all HTTP requests made for the current page.
http://getfirebug.com/wiki/index.php/Net_Panel
Is there a way copy this list as text, so that I can paste it somewhere else for my own records? I’m doing some optimisation work, and it’d be really handy to save the requests made for pages before I optimise, so that I can check what effect my optimisation has.
Alternatively, are there any other tools that would give me the same file information (i.e. URL of file requested, size of file — I don’t need the timeline stuff that Firebug’s Net panel does) as Firebug, in text format?
FireBug NetExport extension is what you're looking for.
HttpFox provides a list of HTTP requests made by a web page, and lets you copy the list out as text.
It doesn’t provide the nice breakdowns that Firebug does (e.g. CSS, images, etc.), but the data is there.
LiveHTTPHeaders will also do this, try the generator tab for a concise list of the requests.
I am using the negative-text-indent technique I learned to show a text-image to the user, while hiding the corresponding actual text.
This way the user sees the fancy styled text while search engines can still index it.
However I am started to think this sounds like cloaking since I am serving different content to the user vs the spider. However, I am not using this in a deceitful way. Plus it seems like this is a popular technique.
So is it SEO-safe or is it cloaking?
Thanks!
No, this is not cloaking. From what I can tell, you are not actually serving different content, based on whether (you think) the client is a crawler. The content you are serving is just interpreted differently by browsers than by a spider. If you are actually serving different content, why are you doing this?
I'd even go as far as say that it is good accessibility practice. Screen readers will still pick up on the hidden text, text browsers will show it normally, etcetera.
No, this is not cloaking. I think the key phrase in Google's definition is:
If the file that Googlebot sees is not identical to the file that a typical user sees, then you're in a high-risk category.
You're not serving a different file - the content of the file served to GoogleBot is exactly the same as the content of the file served to users.
Thomas is right - this is not cloaking. CResult's quoted text implies that Cloaking is serving a different files for crawlers and users. Meaning, for the context of crawling, Content = File. Thus, if you serve the exact same file, you are not Cloaking anything.
It doesn't matter if you serve off-screen text.
It doesn't matter how the content is presented to the user. It doesn't matter what is inside the file.
At least one blog interprets one of google's help pages as proof that google would not approve of negative indents.
Also, this post which supposedly has a quote from a google employee on the topic.
This is NOT cloaking. I use image replacement techniques all the time. It makes sense in the fact it's more accessible. If the text reads what an image says then that's fine. It is functional to the image. If however, you're cloaking a description of the image that is not otherwise on the image anyway, I'd be concerned about that. It's fine to replace things that read the same. I do use ALT text, but sometimes I'd rather have the image as a background on text and indent it off screen. It meets the same requirements.
Why does Google Analytic request a GIF file?
Is it because the GIF allows access to more data than JavaScript alone. Is it to get the IP address of the user?
Google's javascript has to transmit the details of your page view to their servers some how. Ajax cannot be used across domains, so the only way to submit the information is to request a file from a Google server, passing the necessary information in the query string. To facilitate this, some form of content must be requested using a standard HTML tag. The easiest way to do this without impacting the page itself is to load a 1x1 transparent gif. Note that in the case of the Google script (and others), this image isn't actually added to the page. It's merely loaded via a javascript statement
var img1 = new Image();
img1.src = 'http://path/to/file.gif?otherinfohere';
This loads the image without adding it to the page. The information could also be loaded using a script tag like so:
<script src="http://path/to/script.js?otherinfohere" type="text/javascript"><script>
However, users are more likely to have javascript blocked than images, so the safer route is to request an image. As to why they would use a gif instead of say, a jpg, a gif is safer in case a rogue browser actually adds the image to the page. The transparent gif is unlikely to negatively impact the layout, where as a 1x1 jpg would leave a 1 pixel dot somewhere on the page.
Edit: To add to my comment about users having blocked javascript, a gif request containing static information can be added inside a noscript tag to allow basic tracking even in the event that javascript is disabled. To my knowledge, GA doesn't do this, but some other web analytics providers do.
Even with JavaScript enabled, analytics requests a GIF file. If you look at the GET params of the image, it contains a lot of information about the browser. Stuff like utmsr=1280x1024 (the screen size). Google Code has a list of parameters.
It uses the image request to send information about the browser without an XMLHttpRequest.
Now, to actually answer the original question, Google is probably doing this to get around cross-domain XMLHttpRequest restrictions.
http://www.perlmonks.org/?node_id=7974
The smallest transparent GIF is 43 bytes.
http://garethrees.org/2007/11/14/pngcrush/
The smallest transparent PNG-24 (which can't be shown by older browsers too) is 67 bytes.
http://www.techsupportteam.org/forum/digital-imaging-photography/1892-worlds-smallest-valid-jpeg.html
The smallest (opaque) JPEG is 134 bytes.
The math is simple! Bigger size = more costs.
you can use the __utm.gif tracker without javascript (w some server help)
you can use it in an email message (w some programmatic help before sending the email)
Urchin was developed before AJAX was popular (2005)
It has nothing to do w cross-domain. They could have used JSONP for that.