#4 Web Performance Basics
#performancematters #fastweb #jvmtech #jvmperformanceseries

#4 Web Performance Basics

Critical Rendering Path

20 years ago the web was simple. To access a website you only needed to request a single HTML file from a server which then rendered as formatted text in your browser. Things changed a lot since then. Today websites consist of multiple files that need to be processed and downloaded by the browser to fully render the page.

Of course this process can be optimized. Before we share a quick tip on how you can do this with your own site it is good to understand the so called "Critical Rendering Path": the browser loads the HTML file first - as in the old days - but then fetches all referenced files and assets. JavaScript, CSS and fonts block the rendering process by default, i.e. a simple CSS @import statement or a JavaScript which fetches additional scripts can slow down the page performance extremely. Enclosed are some good deep dives.

Reordering the HTML Elements

But did you know you can easily increase the perceived performance of your web app by simply reordering the elements in your page’s <head>? Let’s dive in to see how!

The metric we are going to optimize for with this simple trick is the First Contentful Paint (FCP). It describes the time that the browser needs to give the user a first visual hint of how the rendered page will look at the end of the rendering process. The result of the FCP is not necessarily close to the full page. Generally it is just a few colored blocks as resources like images and fonts still need to be downloaded.

For a speedy experience on your website the first element in your <head> should be <meta charset="utf-8"> - this will overwrite the browser’s default encoding if it’s not already UTF-8. The reason why it should come first is that the browser needs to restart processing the document as soon as it encounters a tag like this as it might have parsed content with the wrong encoding already. 

A similar reason applies to <meta http-equiv="X-UA-Compatible" content="..."> which should come as second. Though note that this one (with all other http-equiv tags) should better be transferred as HTTP headers as those can be processed before rendering even starts.

Another common tag is <meta name="viewport" content="width=device-width, initial-scale=1">. This should come next - but especially should come before you load any of your custom CSS. That is because the viewport is actually evaluated like CSS and would cause a reflow. If you put the tag after your CSS, a reflow that would be visible to the user which you don’t want.

Now there’s room for your <script> tags or better your one and only <script> with your bundled JavaScript. The reason why it’s good to bundle is that it will decrease the number of requests that have to be done to show and use your website. When embedding your bundle the following should be common by now: use the async attribute. Otherwise the browser will completely halt rendering until the JS has been downloaded and executed. That’s because the browser can’t not know if your script might do things like document.write() which would have influence on rendering. With the async attribute you’re promising the browser that your script isn’t needed to render the page and can be downloaded and executed asynchronously from rendering.

Last but not least now add your stylesheets to the mix before adding any other tags like <meta name="description" content="...">. There are multiple ways to go about your CSS. The first one would be to use a <link rel="stylesheet"> element to point to your external source. The problem with this is that the browser again needs to download the resource before it can proceed with rendering. But lucky you there are two ways to work around this bottleneck. You can either add the CSS that is needed to render the page above your fold to a preceding <style> element or you can think about inlining your CSS all along making the need of other external pages unnecessary.

However these simple steps should help you increase the perceived performance of any website. Simply by reordering the elements in the head of your page.

Tomorrow follows: 5# Network Optimization.

Thx for sharing! It had an immediate visible effect ⚡️

To view or add a comment, sign in

More articles by Thomas Feldhaus

  • The speed of use

    At the previous article "The perception of performance" we found out a lot about the human perception of time and speed…

    1 Comment
  • #19 The perception of performance

    Do milliseconds and kilobytes make the difference? In the previous articles on performance we have heard a lot about…

  • #18 Building a web performance culture.

    Web Performance is not a product feature that can be easily switched on and off, ideally the entire organization…

  • #17 AMP, Performance built-in.

    For 16 episodes we have now bombarded you with tips, tricks and ideas how you can improve the speed of your web app…

  • #16 Webassembly

    WebAssembly or short Wasm is a huge deal as it is enabling deployment of lower level language code on the web for…

  • #15 Image & Video Formats

    In the first years, the Web was a text-based wasteland with only a few image oases available solely through links. This…

    1 Comment
  • #14 PWA/Service Worker

    When thinking about performance, web technologies always had a reputation of being slow and sluggish, especially on…

  • #13 Web Performance Timing APIs

    If you are into web performance you surely stumbled upon very detailed numbers. No matter whether you measure…

  • 12 Javascript defer or async?

    When adding interactivity to our web pages we heavily rely on JavaScript. But adding JavaScript comes with a price.

  • #11 JavaScript Performance

    Nowadays, web applications are heavily interactive and make use of lots of JavaScript. May they be scripts we wrote for…

Others also viewed

Explore content categories