Some of the real solutions to render lock error and improve performance

Asked

Viewed 443 times

7

Well, lately I’ve seen, in articles about performance, some Angouts, and also in groups on social networks, about such a "blocking of rendering content above the edge". But what is this mistake ?

Well, in short, this error is caused, because when loading files in the header of the html page, as usual for CSS, the rendering of the code can be interrupted to download the requested files (if there are more than 2 files, it starts to delay a bit)this is given because the HTTP protocol can only process 2 connections at a time, so if you load your HTML, with 3 CSS files or more (there are projects that can use more than 10 CSS files up), the page stops being loaded/rendered, for the requested files to be downloaded, up to 2 at a time.

How to fix this easily and simply, and how to improve my performance with more techniques ?

1 answer

12


Well, first of all, after a lot of research, some crucial points I found were:

  • Do not separate your CSS by components (header.css, footer.css, body.css, grid.css, gallery.css);
  • Avoid using compressors unnecessarily (why use a compressor in a 30kb code?);
  • The recommendation not to put CSS inline inside the HTML page is not to be taken literally (explained below with the examples);
  • Putting links to the CSS inside the header, one can somehow consider a bad practice (not in all cases, like a CSS of +/- 80kb for example).

Anyway, after these points, I’ll explain some ways to fix the problem with blocking, so you can rank better in the insights and other sites that test performance:

1 - CSS compression and "decomposing to recompress"

To begin the performance improvement of your code, a minification of the code and a better separation are the key, I will not go into much detail on minification, but for the "decompression and recomponentization", the best thing is, you identify all the patterns of your code, separate what is priority, for example, the code from a menu, which is the same on all pages, or that of a footer, the grid that you create for your site, put them all within a file, usually using the "patterns.css".

The styles of each page, to be separated with the name of the page itself (for example: index.css, sobre.css), but only the unique patterns of each page, those that are of some pages, but not of others, can be used as something like "sub-standards.css" or something like that, this can considerably decrease the number of requests per page (and all this goes pro javascript too, the comments serve for the organization of the code, you can and can componentize patterns within a single file)

Example:

.yellow{font-size:1em;}
.blue{font-size:1em;}
.red{font-size:2em;}
.green{font-size:2em;}

You turn to:

.yellow,.blue{font-size:1em;}
.green,.red{font-size:2em;}

Then you see that, all pages use green and red, you separate them in the standard.css file, while Yellow and blue are in the file of the page that uses them

2 - CSS inline (within HTML):

"Ah, that one I don’t even read because I’ve been told it’s wrong to do it".

First of all, whether it’s wrong or not depends on the size of the project, of course we’re not going to put 500kb of CSS inside the HTML body, but if it was really something restricted, there wouldn’t be a tag, and it’s precisely the use of it that we’re going to talk about.

Let’s assume that we have the following code within index.css:

.grid-items{align-self:flex-end;flex-grow:1;}
.green,.red{font-size:2em;}

Assuming, this is the primary pattern your page should receive before any other style. instead of using a request to pull the patterns, we can put them in html using the tag quoted above, leaving something like this:

<style>
    .grid-items{align-self:flex-end;flex-grow:1;}
    .green,.red{font-size:2em;}
</style>

"But it’s not wrong ?" - Not if you don’t fill it with unnecessary code, and also, Google itself says in its performance documentation, that prioritizing code and putting inline priority within html is the right way

Pros: Improved page loading.

Contra: difficulty in maintenance as the same default CSS is applied to more than one page.

  • How to fix against ? - If you use . php, it’s quite simple to solve the problem, just that instead of deleting your.css patterns and putting the styles inside the tag, you open a space for php inside it and use the file_get_contents() specifying the path to your css (something like "css/standards.css")

  • But another counter arises: it is almost unlikely to be able to put the content of two style sheets in the same tag and most likely, even creating another, it will still go wrong.

3 - Place all scripts and links after tag <html>:

What do you mean ? That doesn’t escape the recommendation that CSS has to stay in the header, and javascript in the footer ?

Well, it depends on which fonts recommend this, as Google itself recommended the inline style. anyway, to solve the last problem (that of blocking the rendering), we will just need to pass all the requests of scripts and css files to the end of the document, after closing the html tag, so that the whole page can be rendered, and only after complete rendering, files are downloaded.

Cons: Depending on the size of the project, it may be that only html appears on the screen for a short time, until the styles are rendered after the page.

Here are the performance tips, but as a small Bonus, follow some links that can help a little more:

-Image compression without loss of quality

http://compressjpeg.com/pt/

-Google Tester for Performance

https://developers.google.com/speed/pagespeed/insights/? hl=en-BR

Web optimizations and asynchronous loading

http://blog.caelum.com.br/otimizacoes-na-web-e-o-carregamento-assincrono/

  • 1

    Almost all the cons have already been solved by automation tools (webpack, Grunt, Gulp)

  • 1

    Yes, but there is still a lot of developers, who don’t use these tools yet, so we need ways to solve these problems quietly

Browser other questions tagged

You are not signed in. Login or sign up in order to post.