To increase performance at the site I work for, we started separating static webfiles from dynamic pages using a separate hostname and web server for static files a while ago. For this, we placed almost all of the images, style sheets and Javascript files on a separate server and installed Cherokee for light and fast web serving on that server. And it worked. Loading of images became easier, and we could apply some of the server-related suggestions from Yahoo!'s Exceptional Performance.

However, Cherokee didn't always try its hardest to serve us well: sometimes it decided to pull the server's load to a performance-decreasing number, configuration of much needed features was "not yet implemented" or buggy and the software is overall not done yet. Also, the developers have, weirdly, decided to use exclamation marks as separators within the configuration, which is just plain annoying.

So we started looking towards other solutions. And we decided to go back to our other option before we chose Cherokee: Lighttpd. With Lighty, as it's pronounced, we can apply these performance rules:

» Add an Expires or a Cache-Control Header
» Gzip Components
» Configure ETags

I'd like to show you which configuration options we used. The following applies to a default Lighttpd (version 1.4.19) as shipped with Ubuntu 8.10. If you're using a different OS or if you've downloaded Lighttpd yourself, I assume you understand enough of it to translate the following to your own situation.

Add an Expires or a Cache-Control Header
For this, we need mod_expire. With that module, we can instruct Lighttpd to include both the "Expires" and the "Cache-Control" headers in the response. To enable the module, we uncomment this line:

# "mod_expire",

This line is mentioned in a list of modules at the top of lighttpd.conf. If it's not, you should look for the list somewhere else in the file and uncomment the line or simply add it, but without the hash sign.

Next, look up a line that says 'expire.url'. It should be there and commented by default. Uncomment it and configure it to do what you want it to do. For us, Lighttpd is entirely dedicated to serving static files, which all need to be cached by the client for a long time. Let say, for documentation's sake, we choose two weeks as the caching time. This would then be our configuration:

expire.url = ("/" => "access plus 14 days")

This leads to these two headers when a URL from the Lighttpd-server is requested:

Expires: Thu, 25 Dec 2008 13:30:31 GMT
Cache-Control: max-age=1209600

And that's it! Enable the 'expire' module, configure the expire time, and you're done.

Gzip Components
To apply gzip encoding of the repsonse body, we use mod_compress, which is enabled and confgured by default. However, not everything we want to compress is actually being compressed, so we change this:

compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css")

into this:

compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css" ,"image/jpeg","image/jpg", "image/gif","image/png")

Over time, we might add other mime-types we forgot to include, but the above covers most of the requests.

When requesting an image with any regular browser, it will be sent to us, gzip-encoded. If you're using FireFox with the Live HTTP Headers extension, you can find these in the response headers:

Vary: Accept-Encoding
Content-Encoding: gzip

This confirms that it's working.

Configure ETags
This is the easy one. In our default installation, a request to the server gave us this as one of the response headers:

ETag: "2832627283"
Last-Modified: Wed, 10 Dec 2008 13:16:32 GMT
Content-Length: 1395

Because we currently use one server for the static serving, this is all we want. So we're done.

And that concludes the confguration of Lighttpd as the optimal static-files-webserver.

It's one of those facts that you learn once and then always remember: if you want your URL's to be properly indexed: don't stuff them with querystring-data. Make them nice, like they're static URL's. That's what I always knew. Like riding a bike, you never forget it. But Google says this isn't exactly true;

We've come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static.
Google Webmaster Central Blog

Not only does Googlebot read dynamic URL's just fine (and now I think of it: why wouldn't one of the largest tech companies make any progress in this area over all these years?), they actually favor it if a dynamic URL is the 'original' of your URL scheme. Googlebot will figure out the parameters and do the indexing the right way.

Of course, static-looking URL's are still nicer for a user to look at, and sometimes a URL that doesn't have querystring-parameters can still be dynamic, but for Google's sake: don't rewrite it just for them. Good to know!

The Next Web: "I feel sorry for you to type in mail.google.com as it’s six characters longer. That seems like a minor effort, but let’s assume you check your email ten times a day. Then, all of a sudden, it’s 60 characters extra. Now consider the number of Germans using Gmail, probably millions, and multiply it with 60. All this extra typing work for the copyright needs of one man."

Oh, come on. Don't you ever re-enter URL's in your browser? That's right, your browser recognizes what you're typing and comes up with suggestions. And if even that is too much, the've added this newfangled feature that, I think, will become a big, big hit. They're called bookmarks.

I like conferences. They bring a combination of information, context, some discussion and all kinds of impressions to you in audible form. In a form that doesn't require you to browse through blogs or magazine articles. Also, you can reflect on the subjects with others during the break times. Or just reflect on it by yourself. In some way, it differs from just reading about the topics on weblogs or online manuals, it's got a different vibe. One I like.

So last weekend I went to the Dutch PHP Conference. I went last year, and I liked it, so attending this year's edition seems logical. But after a day of listening to some interesting talks I'm wondering: who is the indented audience for this conference? Am I even in it?

Let me explain by walking through the day. After @ijansch's opening, we were welcomed into the history of PHP by Zeev Suraski, one of the founders of Zend and with that, one of the people who made PHP what it is today. It's nice to hear the story from someone first-hand, as opposed to reading it in the PHP Manual.

He gave his view on PHP today: it's mostly done, and our focus as a community has been, and still is, shifting to frameworks. In a way that's like saying "we've been building the car for a few years, now it has become time to do some driving". And he's right. PHP is never truly done, of course, but it is fairly done, and now it's up to the frameworks to mature and become the highly useful, production-ready toolkits we all need (yes, need, even though some of us might not know it yet). In my view: some parts of frameworks wille eventually become more attached to the core of PHP, as often-used parts will grow into the extensions area.

After Zeev, Marco Tabini, publisher of php|architect (which I'm subscribed to), explained how important mayo is to the PHP world. No, wait, that wasn't it. He wasn't very PHP-specific, but his keynote was quite interesting nevertheless.

Lunch came and went, and the breakout sessions started. I attended the ones presented by Gaylord Aulke, Lorna Jane Mitchell and Ivo Jansch.

Gaylord talked about how you would go about creating, maintaining and using an infrastructure when you're working in a team. He explained about development locations, version control management, test- and staging servers and deploying your work to a live server. This very much connected with Lorna's talk, which focused on deployment in general, and on doing that with subversion in particular.

Both talks were interesting, but only small bits of it were giving me new information or a perspective I didn't think of before. Both gave me the impression that the intended audience would not include people already working in teams, with version control already very much in place and several live projects to maintain. Those people would already have invented (and/or implemented) the proverbial wheel for their own situation. Which is the case for me: at both of my jobs, an infrastructure is in place and working nicely. Nevertheless, both talks were interesting, and some viewpoints offered, along with a nice feeling of confirmation, some food for though and/or Googling.

After the break, the choice was to be made between Stefan Priebsch's session on the upcoming PHP releases, a session by Matthew Weier O'Phinney about best practices within Zend Framework (this description is not as accurate as it should be, but we'll get to that) and Ivo Jansch's presentation about Enterprise PHP.

Because information about PHP 5.3 and 6 can be found on the mailing list, wiki pages, blogs and the slides Stefan posted before the conference, that one was an easy choice: no need to attend. The session on Best practices within Zend Framework would only make sense if you were actively using ZF, I thought, so that would not be very practical at this very moment (I was wrong, as you can see by reading the actual description on the site, it's not 'within' Zend Framework, but 'inspired by' it, if I understand correctly). So I entered the room in which I would be very cautious about product placement (kidding).

Ivo's session had 'Enterprise PHP Development' as its title. Because I work in a couple of teams/environments where the label 'enterprise' might, in some way, be a suitable one, I thought I'd attend this session. It's always nice to get some tips, attention points and such. But, the session was basically about the same as Gaylord's and Lorna's. Not that he covered the same topics, but again I felt like I knew a lot of it already. He covered ten main points you need to be thoughtful of when working on your projects, of which some were very obvious, and others inspired some thinking while in itself not being new (to me, at least).

After all this, my colleagues and me were interviewed for a Bachelor ICT video, in which we expressed our concerns about the lack of depth in the sessions. Terry Chay had already started his keynote by that time, so after missing the beginning, we hurried in and stood in the back, while listening to a very interesting and nice keynote. Chay is a wise man, I said to myself.

Looking back at the day in its entirety, I think I expected more. I already called my feeling about the sessions a 'lack of depth'. This of course isn't necessarily a bad thing. A PHP Conference, especially one in a community that's still growing and has a lot of people still learning how to be the best, should be aiming for a wide audience and not exclude beginners. However, if some f the sessions would last longer, maybe the contents could become more hands-on and give you more the feeling you're walking away with lots of information to research in the days or weeks after the conference.

I'll probably attend next year's edition, but can I silently hope for some more advanced content?

I've got lots of content in my RSS aggregator that I "want to read, but not right now". And I keep skipping over it, making sure I don't accidentally mark those items as read, and that is starting to annoy me. So I'll just do what every sensible guy does: make a note of those items and move on.

Adding to that, I thought I'd just share them with you, so here is my to-read list:
» Q&A and Recording of the Memcached Webinar
» How would you compress your MySQL Backup
» Please Give Us Your Email Password
» Give Your Site a Boost With Memcache
» MySQL Proxy: debug plugin
» MySQL Cacti templates 1.0.0 released (screenshots)
» Tools to use for MySQL Performance Review
» Designing For Evil
» Videos in the Flickr API

There. Now I can clean out some items in my aggregator. I'm gonna do this more often, by the way.

Paolo asks whether it's a good choice to start a promotial site for Italy with some flash intros. I think it's not. This is what I posted as a comment:

I don't like the flash intro. It has no use whatsoever and it makes me wait. So if they could drop that one, it would be great.

Second, I get the intro with the language choice. Now, that one does have a function, but I would guess that the majority of visitors speak English, so it's probably better to open with the English site and make it clear that an alternative language can be chosen.

I don't really mind the third flash thingy on the site itself. After all, it's a tourism site, so some sights of the country are okay, as long as all the information can still be easily found.

So to all you webdevelopers out there, pondering on the possibility of a flash intro: don't. Please don't.

I'm not very active on this blog, mostly becase I do most of my blogging in Dutch and even that actually isn't much. But: I'm a Google Reader user now, and every so often I click on Share when I think an item is interesting.

So if you want to read what I think is nice, have a look at my shared feeds.

A List Apart: "When you visit the site, it welcomes you with a random language. Hola! Salut! Shalom! When you log in, the button says “Get in there” instead of “Submit.” When you upload a photo, join a group, add a contact…all of the associated text is open, encouraging, happy, and excited. And it has a significant impact on the overall user experience."

I was thinking about this a few days ago. A big part of the feeling you get when visiting Flickr, is the way they address the user. It's always happy, cool and easy. Servers are never down, they have massages. They have 'Interestingness' as the name for a feature. It's just cool.

More websites should communicate like that. It makes me like them.