async vs defer

[oscarbaruffa]

I noticed that the js tracking snippet now has "defer" in place of "async" - should I be refreshing my older sites' js links with this or will it make no difference?

eg <script async data-domain="mydomain.com" src="https://plausible.io/js/plausible.js"></script>

is now

<script defer data-domain="mydomain.com" src="https://plausible.io/js/plausible.js"></script>

[metmarkosaric]

you can keep it or change it. there probably won't be much of a difference either way. we had them both in the script at the same time and removed one of them after this post #602

[oscarbaruffa]

Cool, thanks!

…

On Sun, 15 May 2022, 17:32 Marko Saric, ***@***.***> wrote: you can keep it or change it. there probably won't be much of a difference either way. we had them both in the script at the same time and removed one of them after this post #602 <#602> — Reply to this email directly, view it on GitHub <#1907 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6QA2KYUYYNGTRW2QL7WX3VKEKJJANCNFSM5V7CPOIQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cptaffe]

I used defer initially, but ran into an interesting issue. In this case, the Plausible script is held in the pending state for one minute exactly, before failing with net::ERR_NOT_RESOLVED ¹. With the defer tag, the request to fetch the script doesn't block parsing of the HTML but it does block the first paint -- so the entire site is left blank if the script fails to load. By contrast, with async the site loads as normal regardless of the script failure.

In light of this, I would recommend using async as the default -- it leaves the site less vulnerable to issues with the Plausible server.

Footnotes

1. The root cause here was a network security system, but this behavior could be caused by any DNS-based blocker like Pi-hole as well. ↩