Comment by ashray | Hacker News Reader

Comment by ashray | Hacker News Reader

Parent Full thread

CSS/JS - Make sure you load these externally so that the browser can actually cache them.

CDNs - Make sure you add a Cache Control (max-age) header to your CDN sync. This doesn't happen automatically through most syncing mechanisms. Helps you save on those pesky HTTP requests that cost $$$.

Gzip - Do not gzip images. It's not worth it. For HTML/JS - YES!

Javascript - If you have ads, definitely load them asynchronously (they go through multiple servers and take ages..). This is really important as you want your document.ready to fire asap so that your page is usable.

POST - Always redirect after a post request to prevent reloads causing re-submits.

Forms - always have a submit button for accessibility.

Usability - Try using your site with a screen reader, don't neglect vision impaired people. (there are apparently a lot of them!)

data-x attributes will destroy your W3C validator checks. Use them if that's not important. (sometimes it just is...)

For external scripts that use document.write go take a look at Writecapture. It's a document.write override which will make your external scripts asynchronous. (https://github.com/iamnoah/writeCapture)

I don't see why counts and pagination are such a big deal. Have done them correctly multiple times. Faceting might be hard though ;) It's a useful usability feature to show counts. (or atleast show counts when there is nothing - i.e. a zero count)

Those are the ones that I could think of right now. :) Great article, some good points in there!

Redirect after POST is not sufficient. Think about users clicking twice quickly (by accident or intention) before the browser receives the redirect. CSRF tokens could help if in place, however disabling the trigger until the redirect arrives is better. Of course this does not solve double-submits using Ajax.

Ajax or no, disabling the submit button/event target is pretty trivial compared to the complexity of doing the rest of your app. Just disable the button when it's clicked, or add a disabled class to the link and a separate click event for it that stops propagation. Or even simpler, just hide it. And do it before it gets around to sending the request.

That's what I tried to say.

Regarding Ajax I just wanted to make clear that it's pointless to wait for the redirect... even if it's send back as response it would not cause anything like showing a different page afterwards.

Author here. Glad you like it.

> data-x attributes will destroy your W3C validator checks. Use them if that's not important. (sometimes it just is...)

Are you sure that is still the case if you have the HTML5 doctype?

It should work fine with HTML5 :) Just that HTML5 is not actually a proper spec yet..

Aside from possibly hurting the W3C Validator's feelings, does that matter?

Some companies policies require validation and they require specs that are nailed down. In those cases you'd end up using HTML <5 and that won't validate with data-x.

I understand the allure of an objective way to evaluate the "quality" of your code... but that seems ridiculously naive. I'm pretty confident I could come up with something that uses features in the spec that nobody ever implemented, so it would be fully validated and correct and yet totally nonfunctional for actual users.

I'm curious why you wouldn't use <!doctype html>? Are you using something in XHTML that's deprecated in HTML5? Those are few and far between.

In that case, decline to work with said company.

Then the validator is not really a proper validator yet. It's 2012. HTML5 is a proper spec alright...

HTML5 is a working draft spec. It hasn't been finalised yet. This isn't usually important for most of us but companies that like calling themselves ISO900X etc etc. don't usually want to work with draft specs.

http://www.w3.org/TR/html5/

It'll probably be finalised by 2014. I don't get the down votes, if you don't agree then why not ask/explain why ?

The downvotes (I didn't even know you could downvote here!) are likely disagreeing with the idea of validating as a talisman. "It validates! Yay, it must work!". As HTML5 formalises much of what already exists, it's hard to move to HTML5 and break things - HTML5 isn't just video, audio, canvas etc, it's also a more sane doctype, ability to omit attributes that only ever have one value (type on script elements for instance), ability to nest things inside anchors etc.

Also, as we all know by now, XHTML doesn't make any sense with the browsers that exist – particularly as it's rarely actually valid XML, and even rarer, sent with the right MIME.

In short, XHTML doesn't exist in any practical sense and HTML5 subsumes HTML4 + modifying the stupid bits to fit with what browsers actually do. There isn't really any logical reason to not use HTML5 syntax, though of course, using the new features can be problematic.

I understand that your logic for validating is likely your companies decision and not your own view, and I'm not attacking your values or opinions in anyway.

That is how I feel too. Never had any issues with HTML5.

Redirect after POST so users can use their Back button. Nothing more annoying than a "resubmit?" button, especially if resubmitting is dangerous.

> CDNs - Make sure you add a Cache Control (max-age) header to your CDN sync. You need to set both the Cache Control AND Expires header.

https://developers.google.com/speed/docs/best-practices/cach... recommends Cache-Control max-age OR Expires. Cache-Control (max-age) takes precedence over Expires. You don't need both.

Reply on news.ycombinator.com