Hacker News Reader

Comment by modeless | Hacker News Reader

Is it going to get faster? I find that MDN pages load much, much slower than e.g. w3schools, which probably explains some or all of their failure to grab the top spot on most Google searches.

For example, a page like this takes nearly 10 seconds to render on the server before the browser receives a single byte: https://developer.mozilla.org/en-US/docs/Web/Reference/Event...

MDN's content is already good. I'd prefer to see effort put into speeding it up rather than adding more features.

View on HN

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_a...

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.

A static site generator for a wiki?

A cache

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...

> 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.

Wow, you weren't kidding - 10164ms for me. From what I can tell, there's not much dynamic content in the page. Static caching would go a long way there. I'm sure they'd appreciate a pull request from someone with some Django chops! https://github.com/mozilla/kuma

Isn't MDN mostly stactic content? I don't understand why it's so slow... Everything should be served off of static pages on a cdn.

MDN is a wiki! There's a django backend which also uses a node.js web service for wiki templating features.

https://developer.mozilla.org/en-US/docs/Project:MDN/Kuma

Since most pages would be read far more often than they are written, you could probably get good results by 'compiling' the page to a static cache after each edit.

I would go that way too. Static content export, put a CDN in front of it, and response times will get < 100ms, even < 80ms.

I have done some experiments with static exports using dynamic frameworks like Rails, and man, it really makes a huge difference. Of course, if your content is mainly static.

I think you underestimate just how fast and furious the edits can fly on MDN.

Rendering page content after edits is exactly what we do. Most page views are served up from a pre-built cache, either from a straight caching HTTP proxy or from a single DB column.

So? Render statically after each edit.

Yes, that's exactly what we do:

https://github.com/mozilla/kuma/blob/master/apps/wiki/models...

pardon me, but is that function writing to the database for each page view?

Seems to me it's actually writing to the database twice for each page view; once to update the render_started_at property on #845, and once again on #881.

That render() method is called only on page edits or forced refreshes, not on every page view.

Yeah - looks like it's emulating a lock so only one page can be rendered at a time (plus the overhead for database IO to maintain the lock). Is this really the best way to go about this?

Unless I'm missing something important, it's locking so the same page can only be rendering once at a time; if another request that would cause a rebuild comes in while a previous rebuild is still in progress, it gets bounced.

Yes, you are correct. We're trying to limit the system to one rendering per page at a time.

No, only views which hit a stale copy of the rendered page and have to call that render() function. Normal views would (I imagine, I haven't traced it back) use the get_rendered() instead, which checks that the cached version is current and schedules a re-rendering (which obviously requires DB writes anyway) if necessary.

The sad part is that I don't mind waiting that long. For most things, I will skip Google entirely and go directly to MDN and not waste my time sorting through the documentation light results from W3schools. Someday, I might start using Web Platform Docs too.

http://docs.webplatform.org/

Agreed — if anything, this just emphasizes how secondary are speed and design if your content is good.

That said, I like both the new and old designs, and as someone who's spent a lot of time on MDN recently, I've personally never noticed it to be slow.

It's interesting that they decided to write their own wiki. If I remember correctly, they used to use MediaWiki which has fairly straightforward built-in support for scaling used by Wikipedia and its sister sites. (Replicate your database so it sends all read queries to replicas, set up memcached to cache I18n strings and parser results, use Squid so that logged out users don't even hit the app servers, enable APC, etc.) I'd be interested in knowing why they went with the option of a rewrite.

The site started on MediaWiki. But, probably around 7 years ago, it switched over to a platform called DekiWiki, later renamed to MindTouch.

This is way over-simplifying it, but: MindTouch looks like a fork of MediaWiki (PHP) that's had all the database calls replaced by requests to a local web service running on .NET, with a Lua-based document scripting system (DekiScript) added on.

However, MDN ran all this on Linux servers - rather than Windows servers - so our installation was rather unusual. Eventually, the company behind the software decided to drop support for our kind of setup. So, we decided to move over to software we could support in-house, and launched it around June 2012.

What we have now started from the Django-based wiki that runs support.mozilla.org, called kitsune. From there, we worked on getting some practical feature parity with MindTouch. I added a node.js-based document scripting service (KumaScript) that mostly replaced DekiScript for our needs. We worked up some migration scripts, and moved the whole thing over.

It's admittedly kind of an evolutionary mess, at this point. But, at least it's our mess.

MDN focus is on having the best and most complete content. w3schools rank higher on google search but their content is not the best one, and sometimes it is too shallow.

Those working with the web should use better documentation than w3schools, thats a quick tutorial site.

Also MDN is from Mozilla so it is all open source and we can all contribute and help speed things up ;-)

Thanks for the reminder. I decided to eliminate some of the mental noise and just add w3schools to Chrome's Personal Blocklist extension.

We are going to work on performance issues until EOY. If anyone would like to help, we're using a new label in GitHub for it:

https://github.com/mozilla/kuma/issues?labels=performance&pa...

Cool! All the issues I see in the list so far are client issues, but the major issue I see is server-side. Server-side HTML rendering ought to take 200ms or less (a lot less for cached pages), but according to Chrome's dev tools, most of the documentation wiki pages take 500-10000ms to render. Client-side optimizations aren't going to help much until that's fixed.

The new site seems speedy enough to me, but I do remember the old one being so slow it was unusable.

Oddly enough it's reasonably fast for me, always under 2sec.

~2s is not reasonably fast. <100ms is. :)

Sure, but not >10s

Reply on news.ycombinator.com