[TeMPOraL]

That's true. What I personally advocate is: first, learn enough about programming and language to not do stupid things - so your code is already somewhat performant by default, at zero cost to readability. Second, when you're designing, think a little bit about performance and, given two designs of similar complexity but different performance characteristics, pick the more performant one. Three, when refactoring, if you see something stupid performance-wise, fix it too. All these things cost you little time and make your application overall snappier and less likely to develop performance problems in the future.

Beyond that, measure before you optimize, as such interventions will require larger amount of effort, so it makes sense to do them in the order of highest-impact first.

(Also note that "performance", while usually synonymous to "execution speed", is really about overall resource management. It's worth keeping memory in mind too, in particular, and power usage if your application could be used on portable devices. Which is really most webapps nowadays.)