DEV Community: Adriano Luz

Everything You Need To Know To Pass PageSpeed With A Perfect Score

Adriano Luz — Tue, 20 Jul 2021 14:15:53 +0000

How long do you wait for a page to load? Not much time, I guess.

You are not the only one who doesn't like to wait a long time until a page loads. In fact, page loading performance is one of the most important factors for a good user experience on the web.

As Jakob Nielsen says in this article:

A snappy user experience beats a glamorous one, for the simple reason that people engage more with a site when they can move freely and focus on the content instead of on their endless wait.

Page loading performance is so important that google now uses it as a ranking factor in search results. In other words, your SEO now depends on your page performance too.

Because of this, many developers are now trying to optimize their website metrics using google's PageSpeed Insights tool to get the best score possible.

In this post I'll discuss everything you need to know to optimize page performance and get a perfect score on PageSpeed. First I'll present the main factors that affect page loading speed, then, the metrics that are used to measure page performance, the tools used to measure them and finally discuss some techniques to improve page performance.

How The Browser Renders Web Pages

Before optimizing web pages we need to understand the process of rendering pages to the screen.

My previous article presented an overview of how HTML and CSS files are parsed and combined to render a page on the screen. Let's briefly review this process considering the performance related aspects of it.

CSS And Render Block

The process of rendering a web page in the browser starts by downloading the HTML file from a server. As soon as the browser receives the first bytes of the HTML it starts to parse it progressively to construct the DOM tree.

During the DOM parsing process the parser can find a link tag to a CSS file. When this tag is found, the parser immediately dispatches a request to download the CSS file and continues to parse the HTML. The CSS download occurs in parallel with HTML parsing.

Now imagine that the parser finished constructing the DOM but is still downloading CSS files. In this situation the browser can't render anything until all CSS is downloaded and parsed otherwise a page with no styling will be displayed to the user. Worse than that, the unstyled page would be displayed and updated as soon as all CSS is downloaded and parsed, causing what is called a flash of unstyled content (FOUC).

To avoid causing a FOUC, the browser has to wait for all CSS to be downloaded and parsed before displaying the page. For this reason we say that CSS is a render blocking resource.

What About Javascript?

During the HTML parsing the browser can also encounter script tags. Like CSS, the browser dispatches a request to download the javascript file immediately but, instead of continuing the HTML parsing, it pauses until the javascript is downloaded and executed.

The entire DOM construction process has to be paused because javascript can manipulate the DOM by adding or removing elements to it, thus altering the structure of the original DOM parsed from the HTML. For this reason javascript is considered a parser blocking resource.

Another important property from javascript is that it can also manipulate element styles. When any style manipulation call happens from javascript, the browser has to verify that all known CSS has been downloaded and parsed before allowing the script to execute the style reading or manipulation. If the CSS is not ready, the script execution will be paused until the CSS parsing is done to ensure that the script has the most up-to-date style information for the page.

Quick recap:

CSS blocks HTML render
Javascript blocks HTML parsing (and render)
CSS blocks Javascript

Improving Performance

The main goal of website optimization is to improve the performance perceived by the users. The best way to accomplish this is by displaying the first useful bits of information (above the fold content) for users as fast as possible.

Knowing how CSS and Javascript resources affect the process of HTML parsing we can now start to optimize our pages to avoid any render blocking and display the content above the fold faster. Let's explore some strategies that can be used to improve the page performance.

Remove Unused Resources

The most obvious, but often difficult to implement strategy to improve website performance, is to remove unused content. This includes unused HTML, unused CSS and unused Javascript.

The problem of unused content is that the HTML and CSS parsers will have to do additional work to parse the unused content even though they won't be painted. As for Javascript the problem is the same. The interpreter will still have to parse script code that won't be executed.

By removing unused resources you can decrease the script, css and html size, thus improving the resource download time as well as requiring less work from CSS/HTML parsers and from the Javascript interpreter to render the page.

Embed Critical CSS

This strategy consists in splitting CSS files into critical and non-critical and embedding the critical CSS in the page HTML files.

The critical CSS consists of rules needed to render above the fold content while the non-critical CSS consists of rules used only by parts of the page that are not displayed immediately, like components rendered below the fold, modals and hidden menus.

After identifying all the critical rules, a style tag can be used to inline these rules directly into the HTML file. This will void a second network round trip by the browser to fetch the critical CSS. As an effect, the page rendering process won't be blocked by CSS download and the above the fold can be rendered much faster.

Lazy Load Non Critical CSS

Since the non critical CSS is not required on the initial page load, it can safely be loaded after the above the initial fold content is rendered.

To properly apply this strategy, a small javascript is required. The reason being that, as discussed before, any link tag to a CSS resource will cause the browser to pause the render process until all the CSS is downloaded and parsed.

The following javascript snippet can be used to load CSS files after the initial page load:

window.onload = () => {
  const link = document.createElement('link');
  link.setAttribute('rel', 'stylesheet');
  link.setAttribute('href', 'path/to/noncritical.css');
  document.head.appendChild(link);
}

Basically it executes a script to insert the non critical css in the DOM and make the browser download, parse and apply the styles defined in the file. Note that this script will only be executed on the window onload event. This is required to make sure that the initial page has been completely rendered before the non critical CSS is inserted, avoiding this new CSS to block the initial render.

Async Javascript Loading

The script tag supports two attributes that are useful to load scripts without blocking the HTML parser. These attributes are async and defer.

Both attributes can be used to tell the browser to load script files in background while the DOM is constructed. The main difference between these two attributes is the moment the downloaded script will be executed.

Scripts loaded with defer are executed only after the HTML parsing is done. For this reason, defer scripts won't block parsing.

Async scripts, on the other hand, are executed as soon as they are available. If the browser finishes downloading an async script while the HTML is being parsed, it will pause the parsing to execute the script.

For this reason defer should be preferred over async to load javascript.

Resource Preloading

The resource preloading allows the browser to dispatch a request to download a resource that will be used soon. This way, the resource is already available when the browser needs it.

Resource preloading works with any kind of resource like CSS, javascript, images and even json fetched from an API.

The following tag is used to preload resources. Note that you should specify the kind of resource you're loading in the as attribute:

<link rel="preload" href="style.css" as="style">

The preloading is particularly useful to tell the browser to download the non critical CSS before it is actually needed. That speeds up the non critical CSS processing without impacting the critical part of the page rendering.

Use Compression

After tackling all the basic page render blocking strategies presented above, some additional work can be done to ensure that critical resources are loaded as fast as possible.

One of them is by using HTTP compression. All current browsers support gzip and brotli compression. It's also easy to find tools to allow your server to compress files before sending them to the browser.

Improve Server Response Time

The idea is simple. The faster a server can deliver the content to the browser, the sooner the browser can start parsing and rendering it.

However this is highly dependent on the server infrastructure and tools used to build the site. Some ideas to improve the server speed includes optimizing SQL queries, finding and fixing slow code and using caching when possible.

Performance Metrics

It is essential for any performance improvement to have a set of standard metrics to measure if the optimizations are returning a positive effect. Let's take a look at the current three most important performance metrics for web performance.

Largest Contentful Paint (LCP)

The largest contentful paint metric represents the time between the initial request to load a page and the paint of the largest page element above the fold. The largest element can be an image, a video poster, a background defined in css with url() or a block of text.

It is very common to have an image as the page LCP element. If that's the case, the resource preloading can be used to start loading it sooner. Also, it is important to resize all images to a dimension closer to the final displayed size to decrease the file size. Image metadata removal can be helpful too.

This metric is part of the core web vitals and has an impact on SEO ranking. A measured time of 2.5 seconds or less is considered a good value.

First Input Delay (FID)

The first input delay metric represents the time between the first user interaction with a site and the time the browser responds to the interaction.

The main factor that impacts on FID is the time taken by javascript to setup all interaction events for the page. For this reason it's important to execute the minimum possible javascript code at the page load to avoid blocking the setup of input events.

This metric is also part of the core web vitals and impacts your SEO ranking. A measured time of 100ms or less is considered a good value.

Time To First Byte (TTFB)

The time to first byte measures the time between the initial request to load a page and the first byte received as a response by the browser. It is a good metric to measure the server response time.

This metric is not part of the core web vitals and doesn't impact SEO ranking directly. But a good TTFB will help to get a good score on all other performance metrics.

Measuring Performance

PageSpeed

PageSpeed is the main tool to measure website performance. It uses lighthouse to measure and report many metrics and, based on the results, presents a few insights.

It is important to note that the score given by this tool is not what is used by google as a ranking factor. Google, instead, uses data collected from real users (called "field data"). The PageSpeed report can display the field data collected by Google depending on the site's size and relevance.

Chrome Lighthouse

Another way to get a performance report is through the lighthouse tab on chrome developer tools. It can be accessed by right clicking on the page then selecting "Inspect" and navigating to the "Lighthouse" tab.

The main advantage of this tool is that it can be used to measure the performance of sites that are still in development and running on environments not accessible from the internet.

Getting Data From Field

PageSpeed and Lighthouse are good tools to get an overview of a website's performance. But the only way to know the real performance is by measuring it in the field.

Google provides a javascript library to measure LCP, FID, TTFB and a few other metrics directly from the user's perspective. This script can be used to collect all the necessary data and send them to a server for processing and reporting.

It is particularly important to measure the web vitals metrics from real users since this is what is used as a ranking factor by google.

In Conclusion

Website optimization is a complex task. I hope this guide can help you to optimize your website, get a good score on pagespeed and improve the SEO ranking of your pages. If you have any questions, comments or feedback, reach me on twitter at @decode64.

From HTML To The Screen: How Browsers Render Web Pages

Adriano Luz — Mon, 14 Jun 2021 14:41:27 +0000

The most basic function of a web browser is to get a html file, along with
an optional css, interpret them and display a page to the user. It is a complex
process but it is based on basic principles that any developer can understand.

In this post we will learn the basics of html rendering and discuss how we can
improve our html and css from what we learned.

Let's get right to it!

Constructing the DOM

After downloading the html file from the web, the first step taken by the browser
is to construct the DOM based on this file.

The DOM (Document Object Model) is the internal browser representation of a page
and it is represented as a tree.

To better understand how the DOM is built let's use the following HTML as an
example and go over each step of the DOM construction for this file.

<html>
  <head>
    <link href="main.css" rel="stylesheet" >
    <title>From HTML To The Screen: How Browsers Render Web Pages</title>
  </head>
  <body>
    <h1>Lorem Ipsum</h1>
    <p>Dolor sit amet.</p>
  </body>
</html>

To construct the DOM tree, the browser has to first read each character of the
html text file and transform this text into a sequence of tokens.

A token is a representation of a piece of text that has a special meaning and
specific rules about how to handle it.

The example HTML above will produce the following sequence of tokens:

HTML > HEAD > LINK > TITLE > TEXT > /TITLE > /HEAD > BODY > H1 > TEXT > /H1 >
P > TEXT > /P > /BODY > /HTML

Note that not only HTML tags are identified by tokens. The text content from the
title, h1 and p tags generate a TEXT token to identify them.

After transforming the HTML text into tokens, the browser scans each token and
arranges them in the DOM tree structure. The browser knows how to create
this structure based on the order of these tokens and the rules for each token.

Each node of the DOM tree is also used to store additional information about that node
like tag attributes.

The entire process can be represented by this simple image:

The CSSOM

The CSSOM is a structure similar to the DOM that is constructed by the browser
to store the css information for a page.

Like the DOM, the CSSOM is constructed as a tree and the steps required
to generate the CSSOM from a css file are the same as the DOM.

The file is read character by character to generate tokens that will be later
arranged in a tree structure.

Let's have a look how the browser will construct the CSSOM for the following css.

body { font-size: 14px; }
p { line-height: 25px; }
span { color: red }
p span { color: green }

The tree structure of the CSSOM is constructed from the most generic to the most
specific rule.

Each node of the CSSOM contains the css rule defined by the css in addition to
rules inherited from parent nodes. This rule inheritance is also called "cascading"
and that's where the name Cascading Style Sheets comes from.

In the example above it's possible to see that the font-size rule defined for
the body is cascaded down to p and span.

Another interesting thing to note in this example is the rule overriding. The css
defines that all span elements should be red. But all span that are inside a p
tag will be rendered green because a more specific rule p span overrides the
initial rule.

The Render Tree

After creating the DOM tree and the CSSOM tree the browser combines these trees
into a new tree called the "render tree".

The render tree will contain only nodes that need to be rendered by the browser.
DOM nodes representing tags like <script> or <link> tags won't be present in
the render tree. Nodes with css rules like display: none won't be present either.

Layout Calculation

In this phase the browser will read the render tree starting on the root node
and will traverse each node of the tree to calculate the exact size and position
in pixels of every html element on the page.

This step is necessary because positioning, widths and heights can be defined in
the css using relative units like % or em and must be converted to absolute
pixels equivalent based on the browser viewport size.

Painting

And finally, the last step. With every position defined in exact pixel units the
browser can start painting each pixel of the screen to render the page.

Optimizing The Rendering Process

The page rendering process is long and complex. Based on what we learned so far
there are 3 easy optimizations we can do to help the browser to go trough this
entire process and display the page as fast as possible to our users.

The first is, remove all unnecessary html and css from your pages. Unnecessary html
and css that won't ever be displayed makes the browser do a lot of useless
work.

That's because the browser will parse and create the DOM and CSSOM trees
for all html and css and will only detect what should be displayed or hidden
in the render tree construction step.

Second, improve your server response time. By getting the html and css files
earlier, the browser can start the whole rendering process earlier too.

Third, reduce the html and css file sizes. That can be done by removing unused
html/css or by using file compression at the backend. This will reduce the
time needed for the browser to download all the necessary files and will
enable it to start the parsing earlier.

In Conclusion

Browsers are a really complex piece of software.

But some basic knowledge of how the browsers work, specially how they render
web pages are helpful to be able to create better pages.

Tips For Designing A Developer Blog

Adriano Luz — Wed, 09 Jun 2021 12:36:40 +0000

I'm starting a new blog. And what a better way to start it than talking about how I've built it?

Usually developers write their first "Hello World" blog post describing all the languages, frameworks
and coding techniques they have used to build the blog.

But unlike all developers, I won't describe how I built it technically.

First because I used a quite ordinary set of tools: jekyll served from github pages.

Second, because I want to use this first post to set the expectation of what kind of topic intend
to write about in this blog.

In this post I'll discuss how I built my blog from a design perspective and give some tips about
designing personal blogs for developers.

Let's Talk About Design

The goal of any blog is to keep the reader's attention to be able to deliver a message or knowledge
effectively. For this reason you'll notice that my blog has a really simple UI. Some may
call it "minimalist".

It is minimalist in the sense that all that I've done in the UI was just adding a few sprinkles on top
of what browsers render naturally without any styling. You can see that not much changes if
you render my blog without CSS.

The few changes added on top of a raw HTML were added with the goal to improve as
much as possible the reading experience.

Here are the 7 main design elements that I used to build a better blog.

1. Limit Content Width

Perhaps the most important tip. Limit the width of the text.

Long lines are really difficult to read and to keep track of. When readers reach the end of the
current line they won't have the beginning of the line in their field of view if the line is too long.
This makes it difficult to know which line is the next.

It will cause frustration and can make readers lose interest in the content
only because the text is hard to read.

2. Don't Add Distractions In The Middle Of The Text

No pop-ups, no animations, no ads. Nothing. You want your readers to stay focused on the text to be
able to communicate your ideas effectively.

It is very likely that readers will already have other sources of distraction while reading your content.
Don't add another one.

3. Add Code Highlighting

Code highlighting is one of the best tools for software development and can be integrated
into your blog to make code blocks easier to read.

It is also important to add highlighting for inline code snippets. Something simple like
a text with different color using a monospace font is enough to make the inline code
distinguishable from the normal text.

4. Display The Post Date At The Top

One of the most frustrating experiences for a software developer is to read an entire blog post,
test the examples and ideas, fail to make them work and, after a lot of debugging, discover
that the post is outdated.

For this reason, any blog, especially blogs focused on software development, should include the date
of the post at the beginning of the page.

If you have an outdated post that you know that doesn't work anymore, add a disclaimer at the beginning
of the text. Another idea is to write a new post and add the link to the updated version on the old one.

5. Tag Your Posts

Tags are a simple way to give additional context about a blog post theme. But don't add too many of
them to a blog post.

Many tags to a single post means that the content doesn't have a clear focus or some of the tags
are irrelevant. Either case is bad for readers.

6. Avoid Default Visual Themes And Templates

A unique visual style to the blog allows the readers to quickly recognize that they are reading
your blog. The blog UI is part of your branding.

For this reason, avoid default themes or themes that are used by many other developers. Try to come
up with something new.

Keep in mind that the blog visuals should be simple. Remember, the goal is to improve the
experience of the readers and not to distract them with fancy CSS.

7. Call To Action At The End

If a reader reached the end of your content, congratulations!

It means that the reader enjoyed your content and you can use this opportunity to guide them to a place
where they can learn more about the topic.

You can add a link to a related post or a link to your social media where the reader can ask you questions
or give feedback about your content.

Reading Experience

Everything is designed for someone to accomplish a specific goal. When designing a blog for developers
we should think how the design will improve the reading experience and, as a consequence, help the
readers to learn as much as possible.

Are you designing a blog? What design element have you added to improve the reader’s experience?