Skip to content

Instantly share code, notes, and snippets.

@hrj

hrj/WikipediaAnalysis.md

Last active August 29, 2015 14:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hrj/ffc853059a0e76d338be to your computer and use it in GitHub Desktop.
Save hrj/ffc853059a0e76d338be to your computer and use it in GitHub Desktop.
Download ZIP
Analysis of Wikipedia performance issue
Raw
WikipediaAnalysis.md

Navigating to Wikipedia home page was causing a massive slowdown of the browser. After analysis the problem turned out to be due to a long chain of causes.

A] Whenever mouse is hovered on an element, the element and its descendants are invalidated.

This is a known and important issue, but will take time to fix. Issue #89. See Update below.

B] Invalidation causes re-layouting of the whole DOM tree

As a consequence of A, every mouse move causes the body element to be invalidated, and also its descendants. By itself, this is correct behaviour. (Not really, see update below).

C] Re-layouting of inline-blocks was causing new instances of RInlineBlock to be created.

This is bad but by itself it is not terribly inefficient. However, it causes more trouble...

D] A new inline-block element (or descendant) which has a background image fetches the image again

This is correct behavior; it just creates a lot of hits to the network layer since Wikipedia happens to have many elements with background images.

E] Requests which have no cache headers in their response were not being cached

When an HTTP response doesn't specify any cache settings, the User-Agent is free to cache or not cache the response (modulo some restrictions on cache duration).

We had chosen to not cache such responses. It turns out that Wikipedia doesn't set cache headers for its image assets.

The combination of all the above factors led to the following results: While browsing Wikipedia, every time the mouse pointer moved by even a pixel, tens of image requests would be sent, without being cached.

In the next release, we are fixing C and E. This solves the immediate problem.

Fixing A would take time, but will fetch even more performance improvements.

Updates - July 2015

  • A has now been mostly fixed. Some more optimisations are possible. Details in #89
  • B was also optimised. We now avoid a relayout if the hover styles don't involve layout changes. Further optimisation is possible too. Details in #121
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment