Preconnect can be done using the http header:
or via the html:
<link href='https://fonts.gstatic.com' rel='preconnect' crossorigin>
Is there a speed advantage in using the header as the response is made available before the response content is parsed?
Using a response header is slightly faster, and could result in preconnecting sooner, but I'm sure that also depends on the browser implementation and network conditions.
If you consider how the HTML response comes to the client, it's going to see the headers first, before it sees the body. Once it sees the body, it needs to start parsing the HTML and get through some markup before it sees your <link>. On a slow connection, there could be a significant delay after receiving the headers before the markup is parsed.
The Google Developer's site at https://web.dev/preconnect-and-dns-prefetch/ mentions:
A benefit of specifying a preconnect hint in the HTTP header is that it doesn't rely on markup being parsed, and it can be triggered by requests for stylesheets, scripts, and more. For example, Google Fonts sends a Link header in the stylesheet response to preconnect to the domain that hosts the font files.
The purpose of preconect is to allow the browser to setup early connections before an HTTP request is actually sent to the server. This includes DNS lookups, TLS negotiations, TCP handshakes. This in turn eliminates roundtrip latency and saves time for users.
Even in html you add the preconnect value in head tag. It won't make any sense if you add it in body tag as this will just act as render blocking element.
