1&1 script limits
I have recently built a simple image gallery for friends & family - in order to ensure that the pictures are only displayed to people with an active logon I use a PHP script to verify the user before using the "fpassthru()" function to stream the file.
This all worked fine on my development server, but when I moved it to hosting (the terrible 1&1), images started to randomly fail to load. Instead of getting an image the server was returning a 500 Internal Server error.
After much playing with caching and investigations it seems to come down to some sort of limit on the number of scripts that 1and1 will allow you to run. So the only way to resolve it is to run less scripts, or delay the running of scripts.
Sites like Flickr and Facebook use Javascript to fetch more data when you scroll to the bottom of the page - this means you can stagger the load on the server and only load images when needed. Alas, the settings with oneandone are so tight that even the first screen load sometimes caused issues.
The second approach is to reduce the number of scripts run. HTTP is great, apart from one file = one request. Google's SPDY suggestions for HTTP 2.0 overcome this by allowing multiple resources to be downloaded in one request - but it's not especially developed yet and certainly not something that would work with PHP hosted this particular host. Then there is multipart MIME, but browser support for this is flaky at best.
I have currently resorted to using the Data URI Scheme, which allows image data to be embedded in the HTML as Base64 data.
There is of course a down-side to this, and that it takes a while for the script to build the HTML with all the images embedded and a while to download to your browser. Normally your browser would receive the HTML first and then start getting the images to put in the structure - with this method it gets everything at once. Overall the loading time is going to be the same (or even faster) but will appear to be slower as there is a longer period of inactivity in the interface.
A possible solution to this would be to combine the embedded image approach with lazy loading when the page is scrolled, so only having to generate X number of images at a time. Something for another day though.