I’ve been asked by clients to setup a way to receive payments online and that usually means PayPal. It’s not because PayPal is particularly good at what they do, but they are the only provider who is willing to offer the service without insane monthly fees. (We don’t have GoogleCheckout in Canada.)

PayPal is always a huge hassle to setup and test, and this last time was no exception. The developer sandbox was broken for most of yesterday, so I started looking closer at the live site. I could not believe what I found. Here is the firebug profile the page a user for the first step of the payment process.

The good news is that they are using a server called paypalobjects.com to serve up static content. The webserver is thttpd, which is a tiny, barebones and efficient webserver. Perfect for serving up images and css that doesn’t change very often.

It is curious why they bothered with registering a new, longer domain. Using something like static.paypal.com would be easier and a few characters shorter.

But that’s it for the good news.

The page consists of 30 HTTP requests and weighs in at a massive 98k. Perhaps if the page was actually doing something complex this would be justified, but this initial page has a simple set of goals:

1. Show who will receive the payment
2. Show the amount being paid
3. For people with a paypal account: Allow them to login
4. For people without an account: Allow them to register or continue the checkout process

That’s it. So basically, a line of text, a short form and a couple of links.

Let’s see what is involved.

First, they use some javascript (DHTML) to hide what is being purchased. You have to click on the triangle thingy to see what you are buying. Since this is a checkout process, you might assume that what they are buying is important, but PayPal has different priorities.

They want you to sign up with a paypal account, so the login form is given a the majority of real estate. Oh, you just want to complete your payment? Well, then at the bottom of the page is a little link to “continue”. (And the “account optional” is not the default behavior, but has to be explicitly activited by the seller.)

Ok, so they want to convey the “used car salesman” image. Fine. Let’s move on.

Looking at the profile, the actual page is 14k (not bad) and only takes a quarter of a second to load. Great! The problem is, the page will not display until it loads (and executes) the javascript, css and images. Here is the file count:

6 CSS files
10 image files
11 Javascript files

The images are all quite small, but it looks like thttpd closes the connection after each request, and ignores the browser’s request for a keep-alive, so this would slow things down somewhat. None of the img tags have height and width, so that would also slow down page rendering.

The css files could be cleaned up (e.g. default.css only contains a comment - no css!). The only tidy css is something they borrowed from Yahoo - and the sitecatalyst code which appears to be a javascript webstats service like GoogleAnalytics. All of their code is messy with various code chunks commented out, and various notes. It certainly seems incredibly complicated for a relatively simple page. Ideally, they would clean up their css and use a script that would merge the required styles into a single file. But since each css file has a different timestamp - my guess is that the css files are just pushed out whenever someone wants to tweak something and aren’t part of any release schedule. (Scary!)

But, by far the most nasty part is the javascript. They’ve got the site analytics as mentioned before, which can be useful for getting numbers on things like screen size. So, it’s not strictly necessary, but ok. However there is something called PayPalNaturalSearch, which is some embedded javascript code and a separate file that has to do with advertising and search engines. Since people coming to this page are following a link from a website - this seems pointless.

There are 11 javascript files that need to be loaded, parsed and executed. They use the yahoo library - basically for the value-less feature of hiding key information from the user. But even if they really did need something dynamic, they could do this with the single file jquery library for around 20k, and as an added bonus the code to use the library looks much shorter and more elegant than the yahoo library.

Plus having the entire page and files encrypted puts more load on their servers and the clients, so it is even more crucial to make sure that everything being sent is required. It should be possible to make this entire page use 10 requests and 10k.

I’m sure the slowness of their service is a known problem. The proof is their slogan: Pay Fast with Paypal. Clever. Instead of actually putting competent developers on the job to fix the problem, try to convince customers that the problem doesn’t exist!

While cleaning up my webserver, I stumbled across a mini-project called Kvetch that I totally forgot about.

The concept is simple: How to provide feedback to broken or annoying websites?

Now, I admit: Being a responsible interface designer, I’ve sent detailed, constructive, unsolicited feedback to various websites. The result? Usually nothing. Or the dreaded, “Well, no one else ever complained.” (Hey, I was trying to help out. Now I’m a complainer?) So, I don’t do that anymore.

But, in the mostly one-way web, there is something satisfying about sending a message back to the people running a website. So, I created Kvetch which uses javascript bookmarklets and server logs allows you to quickly express yourself.