Please add caching of full rendered wiki pages for logged-out users. I'd much rather get a cached page from yesterday in 100ms than wait 10 seconds for today's edits to be rendered.

Hmm ... it should work that way now. In fact, only admin users can force a page to refresh its cached content.

Though we are getting a spike in traffic with the redesign launch, New Relic still reports app server response times of <600ms. But WebPagetest confirms really slow load times. [1]

If anyone finds some gross offenders of page performance, please file a bug: http://bugzilla.mozilla.org/form.mdn or better yet - send a pull request: https://github.com/mozilla/kuma !

[1] http://www.webpagetest.org/result/131209_Z0_1Q09/

I'm getting response times of 4-5 seconds, which I think is a lot.

This is mainly static content you got there, it's the easiest scenario for aggressive content caching. Just throw in a good Memcached server and serve the whole page from cache. Add some good expiration headers + etags and the website will fly. Unless you have problems with request queueing, which would be a completely different topic.

please make it readable asap, cause it is not.

- darken the text, low contrast destroys eyesight.

- make the text bigger for god sake

- use a serif font for the main text,really,you can keep the headlines sans.

- your website has a big whitespace/negative space balance problem.

I mean,i dont understand designers today. Do they care about readability? or that a site look fancy on their shiny new mac ?

As for performance problems i would suggest moving to a static site generator, a doc is the perfect use case.

> use a serif font for the main text,really,you can keep the headlines sans.

All the web usability studies and web design books I've read that address typography have stated that most people prefer sans-serif typefaces on screens. And the typefaces used by all the top sites reflect this.

I don't have a strong preference either way, but it's important to note that those recommendations came before retina displays. Serif fonts can't be rendered accurately on low-DPI displays. As more people get high-DPI displays, I bet serif fonts will be used more in body text.

This might be news to you, but not everybody has Retina (or equivalent) displays

Umm... That's what I said. "As more people get high-DPI displays, I bet serif fonts will be used more in body text." I was making a prediction, not stating that designers should use one or the other.

If I had to suggest a change in the typography, I'd suggest the opposite. The headings(large text) can have serifs. But the bulk of the body should definitely be sans. Serifs add too much clutter when the font is small.

Add this to your userContent.css: <http://db48x.net/MDN-fix.css>. It fixes the whitespace problems, but I haven't touched fonts. Font size is best corrected by zooming in; Firefox will even remember your zoom level across the whole domain, so you only have to do that once.

A static site generator for a wiki?

That sounds like a good idea, actually. Why not? Generate and store each page each time it's edited, then serve from the static copies. There will be a lot more reads than there are writes anyway.

That's a static page cache, not really the same thing. And I'm pretty sure they're doing this already, or are about to.

We can't generate the whole thing statically, because there are parts of the interface that change with user state.

We do render the HTML for article content, which includes many scripting templates.

We're seeing a lot of interest in the static/caching side of the site. I wonder if we should do a public article about it and invite people to help us improve it.

Can you not serve a static page and then have Javascript fetch the additional, user state-dependent content? At the very least, that will reduce latency for some content.

The public article will surely be interesting even if it is not all that useful...

A cache