Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Moving script from head to top of the body (right after <body>) can trick lighthouse
See original GitHub issueIn one of my projects I could not put JS at the end of page (before </body>). I remove all script tags from head and put them at the beginning of the body tag (after <body>) and lighthouse gets happy. this could improve your render blocking score, but we all know it is not good idea and basically nothing changes, still user have to download script first (based of my knowledge)
Before:
<head>
<script src='/path/to/bundle1.js'></script>
<script src='/path/to/bundle2.js'></script>
</head>
<body>
<h1>:)<h1>
</body>
After:
<head>
</head>
<body>
<script src='/path/to/bundle1.js'></script>
<script src='/path/to/bundle2.js'></script>
<h1>:)<h1>
</body>
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
How to Load Fonts in a Way That Fights FOUT and Makes ...
Let's talk about eliminating font stylesheets as a render-blocking resource, and walk through an optimal setup that not only makes Lighthouse ...
Read more >Introducing Partytown : Run Third-Party Scripts From a Web ...
There's a few tricks to reduce their upfront damaging effects, like waiting until after the page load to run these scripts.
Read more >putting javascript in head and putting just before the body close
If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page.
Read more >How to Refactor a Shopify Site for Javascript Performance
These six steps will help you refactor a Shopify site to improve performance for Shopify ... Scripts allowed just after the <body> tag....
Read more >How To Fix Cumulative Layout Shift (CLS) Issues
The other two Core Web Vitals stop after the main component is found on the page after load (for LCP), or for the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Compared to putting it in the head, yes it marginally will. Compare https://melodic-class.glitch.me/script-head.html vs https://melodic-class.glitch.me/script-body.html with “Slow 3G” throttling turned on. Notice that the background color is able to render after only 2s when in the body compared with 4s when in the head. While there’s going to be virtually no difference for the content, it does marginally improve the UX + speed index.
For the opportunity? Yes, I feel confident about that. If it’s not in the head, it’s not technically render-blocking. If we wanted to capture “important content blocking” then we can rename the audit and change its impl 😃
For lantern, we don’t ignore them. If they’re early in the body they’ll be issued with
Highpriority and be swept up into FCP graph (assuming they meet the other criteria we’re looking for to filter out definitely non-render-blocking things.https://github.com/GoogleChrome/lighthouse/blob/a5ff4f51abf430950cde2a53e9cee085d908c6de/lighthouse-core/lib/dependency-graph/network-node.js#L81-L88
Script tags in
<head>will block rendering, while having them at the end of<body>won’t.It’s quite similar to
<script defer>in my opinion, while I believe<script defer>do start the download earlier than<script>locates at the end of<body>