6 ms·

MDN dev here. Page-load time is one of our immediate next goals. Tons of traffic to our document view and lots of potential back-end processing on each doc kind

MDN dev here. Page-load time is one of our immediate next goals. Tons of traffic to our document view and lots of potential back-end processing on each doc kinda sucks. But, we're using New Relic now and hoping to tackle things iteratively as we go. https://developer.mozilla.org/en-US/docs/Project:MDN/Plans_and_status/Server_charts https://developer.mozilla.org/en-US/docs/Project:MDN/Plans_a...

modeless 13y ago
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.
- groovecoder 13y ago
  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 http://bugzilla.mozilla.org/form.mdn or better yet - send a pull request: https://github.com/mozilla/kuma https://github.com/mozilla/kuma ! [1] http://www.webpagetest.org/result/131209_Z0_1Q09/ http://www.webpagetest.org/result/131209_Z0_1Q09/
  - iagooar 13y ago
    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.
camus2 13y ago
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.
- fhd2 13y ago
  A static site generator for a wiki?
  - iand 13y ago
    A cache
  - mintplant 13y ago
    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.
    - fhd2 13y ago
      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.
  - groovecoder 13y ago
    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.
    - 13y ago

modeless 13y ago

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.

groovecoder 13y ago
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 http://bugzilla.mozilla.org/form.mdn or better yet - send a pull request: https://github.com/mozilla/kuma https://github.com/mozilla/kuma ! [1] http://www.webpagetest.org/result/131209_Z0_1Q09/ http://www.webpagetest.org/result/131209_Z0_1Q09/
- iagooar 13y ago
  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.

camus2 13y ago

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.

fhd2 13y ago
A static site generator for a wiki?
- iand 13y ago
  A cache
- mintplant 13y ago
  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.
  - fhd2 13y ago
    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.
- groovecoder 13y ago
  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.
  - 13y ago