Hacker News Reader

Comment by jamesbressi | Hacker News Reader

Ask HN:

I'm sure there is going to be tons of positives to this from the community, many I can identify myself, but can someone list some NEGATIVEs that may arise by using this?

View on HN

Each of the filters mentions risks:

http://code.google.com/speed/page-speed/docs/filters.html

This is a tool that mindlessly applies optimisations that are lossy or change behavior of the page. Sometimes it may break things (e.g. I use `input[type=text]` selector in my CSS, and removal of "redundant" `type="text"` attribute from source would break it).

It also wastes some processing time on applying on-the-fly code changes you could do yourself in the source.

If you follow performance best practices, you may optimize pages better yourself (you need to judge what is better to inline, what can be made async. Simple heuristics of this module uses may be too crude).

Would it? I thought the type defaulted to "text" if missing. I'd be surprised if css selectors didn't recognise that...

CSS sees DOM attributes (what you get from element.getAttribute('type')), and not DOM properties (element.type).

These are different things kept roughly in sync by setters/getters (called "reflected properties" in HTML spec).

The `type` attribute is also supposed to have default value implied by the DTD, but that could only work in "validating" SGML/XML parsers (which browsers aren't).

I didn't know that. I tested it myself and you're right. The "Elide Attributes" filter seems fairly pointless anyway. I can't imagine it making that much of a difference in performance even if it was safe.

I use Smarty as a templating engine and sometimes I have to generate a few lines of javascript or css dynamically on the page based on php variables at runtime. I wouldn't want these to be stripped out and cached.

Usually I do a lot of optimization in the templates. For example, Smarty lets you wrap your output in {strip} tags to remove whitespace and newlines. And I have a script to concatenate and minify javascript and css. Plus mod_deflate on the server. I serve images from s3/cloudfront and there is a script that will use smush.it to compress everything in an s3 folder and set the expires tags.

It looks like the 'Optimize Images' filter rewrites a different file name for the optimized image:

Before: <img src="images/BikeCrashIcn.png" alt="Bike Crash">

After: <img src="images/images/ic.HASH.x,BikeCrashIcn,p.png" alt="Bike Crash">

If you get significant search traffic from Google or Bing Image Search you'll probably want to disable this filter.

What in particular about the rewritten filename would be detrimental to image search traffic?

The filter retains the original filename as well as the alt text.

The search engines will spider/cache the resized version, so people looking for a higher resolution version, may skip over your site?

Given two image filenames: "pogo-sticks.png" and "ic.HASH.x,pogo-sticks,p.png", I'm willing to bet the former will rank higher and lead to more pogo stick traffic and sales because of the straightforward filename.

From the horse's mouth: "optimizing your image filenames and alt text makes it easier for image search projects like Google Image Search to better understand your images."

http://static.googleusercontent.com/external_content/untrust...

Anything that makes it harder for Google to understand your site is a losing business proposition.

I'd rather use PageSpeed for Firefox (optimize in dev, set the appropriate filenames, then deploy to production) to avoid any possible ranking penalties caused by this filter in production.

I'm surprised it doesn't convert to (and if possible serve in) WebP, the image format created from WebM.

It was these guys (the "speed" folks) within Google that came up with the idea.

http://code.google.com/speed/webp/

Maybe in a later version?

If you click on the individual filters to read their descriptions, they all have a "Risks" section at the bottom of the page. For example, the inline css removal filter has this:

The 'Inline CSS' filter is low to moderate risk. It should be safe for most pages, but it could potentially break scripts that walk the DOM looking for and examining <link> or <style> tags.

The biggest negative is people implement it without understanding and just enable all the filters by default.

It's also another apache module. Personally I try and work without DSOs.

I agree with this comment. Interestingly they're trying to implement it on Go Daddys systems for 8.5 million customers. This suggests they must be fairly confident that the optimisations are safe for the vast majority of sites.

I wonder which filters Go Daddy will enable and how many problems it will cause.

It sounds a bit paranoid (and surely technically unimportant), but the first negative aspect that i think of is :

this is putting Google into our servers, too.

Reply on news.ycombinator.com