Ben Zajac’s Blog

Programming, Flash, IT, and sadly, SEO.

Pareto principle (80/20 rule) and SEO

This week in SEO advice:

Pareto principle is also referred to as the 80-20 rule. It says that 80 percent of your effects will come from 20 percent of the efforts.

I tend to find this applies to SEO as well. 80% of what most people do to be more SEO-friendly generally doesn't help as much as that 20%. That 20% that leads to 80%, in my opinion, consists of:

- Quality content / Keywords

- Freshness

- Site speed

- Link Building / Notoriety

 

The 80% that leads to 20% consists of:

- Nitpicking over Meta Tags

- Making that image that says "Search" text so the word "Search" appears in your HTML (Anyone ever recommends that to you, run for the hills. You will never win the keyword "Search")

- Stripping out extra whitespace

- most of the "HTML optimizations" SEOs pitch

 

So when you spend your programmers man hours, running up tons of man hours on things like stripping extra whitespace out, realize that for the same price or lower, you could have gotten someone to do a few man hours of link building or copy writing that would have driven much more of your traffic.

 

Starting from scratch ft. Carl Sagan's Whoop ah ah

I saw this a long time ago, but I recently saw it linked from somewhere else. Someone remixed Carl Sagan into one of the greatest youtube videos of all time. It makes me feel good about humanity. If only it had 5 million views, it would beat the weekly viewership of the Jersey Shore. Seriously, this video has less views than the Jersey Shore. That hurts. A lot.

I can't get enough of it. But I really wanted to point out the line: "If you want to create an apple pie from scratch, you must first invent the universe." I love it. As a developer, that statement comes up all the time, create from scratch. "The framework is really slow, lets create one from scratch." "This module doesn't do what we want, lets create a new one from scratch." "I know we don't want to reinvent the wheel, but we have to create it from scratch." Sometimes starting from scratch can be a good thing, but very often, the people saying "start from scratch" don't realize the whole scope of what they are saying. Starting from scratch on something is time consuming and requires a lot of engineering, architecting and coding. So for the "start from scratch"ers out there, remember, you must first invent the universe.

How Flash's DisplayObject.cacheAsBitmap saved my life

Tweening displayobjects. That's supposed to be Flash's bread and butter. Animations, movement, things like that. Recently I was coding some Flex 4 stuff, and I was updating the x position of a small element on the page every 100 milliseconds (on a timer). The object overlapped some other custom drawn elements. When the timer was enabled, CPU usage was around 40% (on a dual core, so that's like saying 80% to single thread/core only flash player). It seemed like a small tween/animation. But it was using massively large amount of CPU time. I panicked. This was the first of many tweens that would happen in the project. If it can't even manage one, I'm screwed. So I began investigating. That's when I discovered cacheAsBitmap. No, not on the moving object. But on the objects behind the moving object. I had a row of textfields and a sprite with tons of little lines drawn on it (a timeline that has second mark ticks and a text field every 10 seconds). When I set cacheAsBitmap=true for the sprite and the textfields, CPU went back down to acceptable levels. Phew.

 

To enable cacheAsBitmap (which is a property on DisplayObject, so anyone descendant from that can do this), you can either in AS3:

 

var myobject:DisplayObject = getMyDisplayObject();

myobject.cacheAsBitmap = true;

or in mxml:

<s:Group cacheAsBitmap="true" ... ></s:Group>

or any other DisplayObject mxml tag.

 

Just don't set cacheAsBitmap=true on a mask, or you wont be happy.

Why jailbreaking/rooting your phone is "wrong"

I was reading this post over at MobileCrunch: http://www.mobilecrunch.com/2010/07/14/droid-x-actually-self-destructs-if-you-try-to-mod-it/


This line from Devin Coldewey got me wondering: "I won’t restate all my reasons for supporting the modding, hacking, jailbreaking, and so on of your legally-owned products here".

I've heard in the past many discussions about this, especially with the iPhone and jailbreaking. People modify the phone software to allow them to do things the software either doesn't do, or prevents for some reason. Now, personally, I believe you should be able to modify this software as much as you want, with a disclaimer that says "Once you do this, bye bye warranty and any type of decent support." I think bricking the phone is completely unacceptable.

But on the devil's advocate side of me, things are different. You bought the hardware. It is your legal property (unless you are leasing it. Read your contracts people). You can modify it, solder it, paint it, whatever you want. That's perfectly fine because you own it. But when you jailbreak something, you are actually modifying the software. This is a different story. You license software. You don't own it. It's not treated as a tangible thing you can own. It's similar to owning a book. You own the paper, the ink, but not the words on the page. With a book you have to respect (respect meaning abide by, not necessarily admire) the copyright, but with software you have to respect license. If you dont like the license terms, then don't use that software. If Motorola's Android flavor has something in it you don't like, roll your own Android flavor and install it over. While that doesn't seem practical, that's the way it works.

Personally, I don't see any harm in modifying the phone operating system software to get it to do what you want, as long as it is for personal use. No harm to others, no foul. Break your own phone, well, that's your problem. But from the standpoint of software is licensed, not purchased, I understand. It's like an author not wanting someone to rewrite the ending to their book.

To sum it all up, if you root/jailbreak your phone or in other ways violate the license/EULA for your personal use, it's "wrong", not wrong.

SEO Lesson for today: Whitespace

So I tend to do a lot of SEO consulting. Mainly from the technical side of things. So I'll share with you a lesson now and again.

Today's lesson: Crawlers don't care about whitespace.

I recently heard from a client that their SEO expert said we need to strip out all unnecessary whitespace from the HTML. Newlines, tabs, all of it. Apparently the whitespace we put into the HTML to make it readable was destroying their PageRank or something like that. I tried to understand how in the world that made sense. Apparently, the people writing all these search engine crawlers and parsers are idiots and were unable to figure out how to make their bots skip over whitespace. The billions of dollars search companies have spent to improve their analyzers of your HTML code, and they overlooked skipping over extra whitespace?!? Sheesh. The ONLY way removing whitespace would help is if you weren't compressing your pages anyway. Then you have bigger problems then whitespace.
Here's a little experiment. I downloaded the clients homepage, which has a hefty amount of HTML and whitespace.
Uncompressed filesize: 106KB. Yeah, that's quite a bit.
Stripping out all \n and \t: 104KB. Not a big difference.
Condense all \s+ into " ": 75KB. Now we see a bigger jump. But wait...
Gzipped 106KB file: 13KB
Gzipped 75KB file: 12KB. Not a significant difference in my mind.

Search engines crawlers and parsers care little about whitespace. How do I know this? Because browsers care little about whitespace. The only thing you will do is shave MAYBE a kilobyte off your filesize, which in the grand scheme of SEO things, is completely minor and insignificant.

My NoSQL Opinion

After reading post after post after post on hacker news about NoSQL solutions being either the second coming or the devil incarnate, I figure I mind as well chime in. Quick and easy, here's how it goes: Right tool for the job. If you have extremely dispersed data that doesn't always follow a tight schema and the hardware to support a NoSQL solution, then use it. If you have data that follows a rigid structure, isn't all that complex, or needs a serious administration language, go with SQL/RDBMS. Comparing NoSQL vs RDBMS in the sense that one is a replacement of the other is a bad path to head down. Both can co-exist.
Choosing which solution to go with should be driven by a few factors. The primary one is application needs. Does your application and data fit better into one or the other, with considerations for speed and connectivity. After that, you need to apply some business needs. What is the cost of one versus the other? Cost can be broken down into numerous things, such as licensing, hardware, bandwidth, and administration costs.

NoSQL and RDBMS are not enemies. They are friends, who want to help you when you are in need. Look at what your application and business needs, then choose. Stop with all the "SQL is now obsolete" or "NoSQL is crap". We need them both.