Skip to content

Better performance to user by smarter page rendering

Description

From gitlab-com/www-gitlab-com!6250 (comment 31859116) :

  • "Browser renders page" is really just the HTML, it still needs to load JS, CSS, images, webfonts before the user can interact with it.
    • Documented on handbook/engineering/performance
  • As the page is streamed to the browser, the browser will be incrementally parsing it, looking for additional resources that it can start fetching
    • DNS prefetch: If these resources are on a different hostname, the browser will need to perform further DNS lookups. You can tell the browser to perform this as early as possible
      • Relevant when we have CDN, until then, not so relevant.
    • Resource prefetch: Additionally you can tell the browser to prefetch full resources, before the page has been fully loaded
    • JS rendering: Depending on where the Javascript is specified, it may block page rendering while the Javascript is loaded. This slows the render process down. Ideally, fetching and parsing of the Javascript should be asynchronous. Currently on GitLab.com it is not. This means that page render depends on all the Javascript resources having been fetched and parsed.
    • More on JS: It's best to load Javascript in the footer of the page, making sure that it's marked as async. However, this should be done alongside prefetching to ensure that the browser can fetch the resources as early as possible.
  • Wherever possible, images should have height and width specified, to ensure the browser can reserve the appropriate amount of space for the image before it has been fetched from the server. If not, the browser will force a reflow once it knows how big the image is. Reflows are distracting as the elements of the page move around, but they're also CPU intensive. - Not addressed, not expected to yield a big performance gain since most images in GitLab are uploads in issues, i.e. not possible to specify height and width ahead of time. Will not address unless we notice more images being used and some amount of layout thrashing.
  • Obviously static assets should be aggressively cached. Avatars, for example have a 5 minute cache timeout which is very short considering how many of them we're loading on GitLab and how infrequently they change. - New issue created, https://gitlab.com/gitlab-org/gitlab-ce/issues/33720
  • Obviously the smaller the resources, the faster they will arrive in the browser. Currently we're not compressing HTML responses. Even with low gzip compression levels, we could be speeding up page loads, particularly on slow connections.

Proposal

Enact each of the points listed above by @andrewn to get a performance gain on GitLab.com (and customer's large instances).

Links / references

gitlab-com/www-gitlab-com!6250 (comment 31859116)

Documentation blurb

(Write the start of the documentation of this feature here, include:

  1. Why should someone use it; what's the underlying problem.
  2. What is the solution.
  3. How does someone use this

During implementation, this can then be copied and used as a starter for the documentation.)

Edited by Ernst van Nierop