This is just a self reference and of course can’t be used in production code. But if you’re willing to test something static real quick and want to avoid file:// protocol you can setup a convenient webserver with python.
Just find the root you want to serve and use:
python -m SimpleHTTPServer
Now just point your browser to localhost:8000.
Bye bye local apache.
I’ve been working with Google Analytics for the last 3 years. When I started working with it it was already a very huge player on the market, but I’ve seen enormous growth on these years. Google Analytics is the most used web analytics solution in the world. It’s used on currently 44.67% of the top million websites on the internet. ga.js is the most popular javascript snippet in the history of the internet.
Google Analytics Usage on top websites:
source: builtwith.com
Imagine the responsibility of the Google engineering team that maintains the ga.js javascript file. While having to deal with multiple recent changes and new features on Google Analytics still have to make sure that their code runs as fast as possible and on all browsers that exist. They must support ie5.5 and low end mobile devices, otherwise these browsers wouldn’t show up on Google analytics reports. Still they must do it while keeping the code from affecting the website performance.
I must say that they do a great work on keeping that code. The asynchronous syntax while confusing at first is a very clever way to push code execution and loading way down on the queue, so browsers don’t delay the page loading to register a GA pageview. It’s clear that the GA team takes great care when it comes to how fast and seamless their code is.
The one point that still bothers me a lot regarding performance are the Google Analytics cookies. Let’s take a look at what GA cookies look like:
>document.cookie "__utma=96182344.347392035.1326382423.1326382423.1326382423.1; __utmb=96182344.1.10.1326382423; __utmc=96182344; __utmz=96182344.1326382423.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" >document.cookie.length 188
This is a minimum GA cookie. It can get longer if you use Custom Variables and Google Website Optimizer. But let’s settle down with the minimum for now.
These cookies are used iternally in GA to keep state and are manipulated by the code on ga.js javascript file. Different from most other cookies you might see out there these cookies don’t need to hit your webservers never. Still they hit your website every single time an HTTP request is made.
According to Google SPDY whitepaper the average HTTP request is 700-800 bytes long. That means that GA Cookies represent about 25% of that HTTP request size. The moment you notice GA is present in about 50% of top websites you notice that useless GA cookies going around the internet represent 12% of all HTTP requests.
I’ve posted a bug regarding this issue on GA-Issues a while ago. The idea is to use HTML5 localStorage to store the cookies on browsers that support it. Still it has attracted no attention so far. This bug fix could easily make the average HTTP request around 5% faster. We’re talking about the average speed of the whole internet.
The real picture is not that bad, since this only affect HTTP requests and not HTTP responses and that’s where the real data is. Still it’s funny to see something that huge going around unnoticed.
Google Analytics released recently the _trackSocial for Google Analytics. It was part of a bigger release on several Social applications including Google+. Sometimes things have to be pushed out before they’re extensively tested, and a couple of bugs may come up.
With the social Tracking one specific bug bit me the other day. Google Analytics won’t apply hostname filter’s to the social interactions, and it may cause profiles that are filtered to only include traffic to domain A, showing social interactions for domain B. From there all sorts of bad things follow: 0 pageview visits, lower pages/visit and so on.
At first I thought about disabling the socialTracking on the +1 buttons, but it seems that the API don’t support it yet. But I found an undocumented feature to disable it. Now you can disable the socialtracking on the +1 button and use Events instead, since they go through the filters before showing up in your Google Analytics profile.
You’ll only want to use it if you are having problems with social tracking and hostnames filter. Otherwise the default behavior is way better since it will populate in separate Social reports.
If you are using the asynchronous code for Google +1 button, loading the syntax is a little bit different.
Thanks Fábio Phms.
This blog was recently infected with a eval(base64 malware. This kind of malware use site vulnerabilities to inject a long list of link in the beginning of pages so it theoretically improves those site’s SEO performance.
This kind of strategy is just sad, telling from the perspective of an SEO.
I came up with a nice oneliner to clear all that nasty code. Works great for me. May be useful for others.
find . -name "*.php" -print0 | \ xargs -0 -n 1 grep -l -Z eval.*base64 | \ xargs -0 -n 1 sed -i'.old' '/eval.*base64/ d'
Essa semana ocorreu o Search Labs 2010 em São Paulo. Eu participei junto com meu amigo Gerson Ribeiro com uma palestra sobre otimização de Landing Pages.
A Palestra está hospedada no Slide Share.