Icon on Fire
Tim joined a company that provided a SaaS solution for tracking attendance and grades in schools. The job was mostly minor updates to a ColdFusion application, although there was an active project to replace it with something more modern. Tim felt like half of his hiring was based on him knowing when to throw out buzzwords like SPA or REST or Reactive Programming.
"It's not the first time," Karmen explained. She'd been with the company for some time. "When I joined, they had just upgraded to ColdFusion from a VBA hack on Microsoft Access. Crazy days, back then, when the whole 'selling service, not software' thing was new. Sometimes, I think I was hired because I knew the right buzzwords."
Ostensibly, Karmen and Tim were meant to be focused on the new version of the application, but the ColdFusion version was so old and so poorly maintained that they spent 75% of their time in firefighting mode. The rest of the team had neatly adapted to the culture of "just put out the fire, and don't worry about code quality, there'll be a new fire tomorrow", which of course only created more fires to put out.
One day, near the end of the month, the webmaster inbox had an alert message from their webhost.
This is to alert you that your account is nearing the data transfer threshold. Your account has transferred 995GB of data during this billing period, with a total account limit of 1,000GB of data allowed. At your pricing tier, overages will be charged at $10/GB.
"Wow, what?" Tim was pretty shocked. He knew they had a goodly number of schools, and were tracking many thousands of students, but there was no way that the application should be serving up 1TB of data in a month. 95% of the application just was text, and while they did have photographs of every student, those photos were only 9kb after resizing and compressing.
"Oh, yeah," Karmen said. "I heard about this a few years back. We had to upgrade to the higher plan with our host. Guess they'll probably do that again."
"I mean, don't you think this is wrong?"
"Probably, sure, but" y'know. Not my circus, not my monkeys." Karmen shrugged, and got back to work on a different fire.
Tim fired up the browser debugger and loaded a page in test that was sure to have a lot of pictures, and was definitely the heaviest page. With 50 student images displayed, the payload of the HTML and assets was a whopping 452KB. That was the HTML and assets" except for one file.
The favicon.ico weighed in at 307kb. Apparently, at some point in the past, someone had decided that it needed to look good at any size. Since the ICO format lets you have multiple resolutions of the image stored at different bit-depths and resolutions, they had made sure to include everything up to 256x256 at 32-bits per color. Ironically, the source image had probably been a much smaller resolution, because the 256x256 version showed clear signs of having been upscaled.
Compounding the problem, since once-upon-a-time there had been issues with browsers serving up cached versions of pages, their web server had been configured to disable caching for every file served, guaranteeing that the favicon would be transferred for every request.
307kb wasn't a lot of data, but it was certainly a lot for a favicon. Even at a massive 256x256 resolution, given the design of their icon, he could fit it into a PNG that was bytes in size- and every decent browser supported it. A quick check of their traffic showed that they still had a good number of users on old versions of IE that couldn't support anything but ICO files, so he cut the massive resolutions out of the ICO file, and whipped up a little CFML that would serve the ICO to those users, and everyone else would get the PNG.
That cut their traffic nearly in half, but Tim didn't get much chance to celebrate- there was another fire to put out.
[Advertisement] Otter allows you to easily create and configure 1,000's of servers, all while maintaining ease-of-use, and granular visibility down to a single server. Find out more and download today!