Tangential to the point being made, 98 as quality seems way too high for an image to be shown on the web. 85 seems to be a decent tradeoff. Doing so might actually increase the image size.
I agree: that jumped out at me enough that I came here to make the same comment. I can hardly think of a case where I'd want to use a 98 quality setting on a JPEG. Maybe it would be a good choice if I wanted to preserve an almost-pristine copy of an original, but I'd compare the resulting file size to a lossless PNG first. Every quality step from 100 down to 95 gives a huge benefit in file size, and going from 95 to 90 almost always seems like a hefty savings for imperceptible differences, too. I usually save web images at quality settings between 70 and 90, and I've never felt like I'm losing by it.
This also jumped out at me. My company (http://www.firebox.com) is built on having amazing looking images for products. No one could see any difference between the quality of images between 87 and 95, but it saved us roughly 50% in file size. Also for what it's worth, we spent a lot of time a/b testing 87 vs 95 with our users, but there was no conclusive difference
We use GraphicsMagick at 92, as dipping into the 80s has an annoying tendancy to introduce visible noise on something like 1:50 images. It's very annoying to ship that extra bandwidth.
Interestingly, we've done WebP support, and while the files are smaller across the board, visual quality deteriorates really quickly once you start dropping that quality value, even in small increments.
True, my app processes around 100,000 images daily and it uses a quality of 85. Never had a problem. But I do keep an archive of the original image just in case