7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets.
This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.
It depends on if you're loading from multiple origins (multiple TCP connections), HTTP 1.1 vs 2 (multiplexing, push, HOL blocking), but generally speaking: yes. If you can fit the content needed to render the page in the initial TCP congestion window, the page will be noticeably faster on high-latency connections.
This unfortunately means, for most websites, some amount of CSS in a style tag in the head to get a basic structure of the page together to start rendering. Then you also include a full stylesheet with the high-fidelity version.
I have done things on my site like inlining CSS and minimizing requests because it feels fast, without knowing exactly why. I didn't know that a single request can actually have multiple round trips!
My WordPress homepage is 2.4kb gzipped and just a single request :) so it is fast but its, uhh, a little boring and only 158 words.
> I didn't know that a single request can actually have multiple round trips!
If you load something from a third-party origin (e.g. 23789dz89asd789s.cloudfront.something), then it can actually be a lot worse than that. DNS needs resolving, which can take quite a while, depending on if and where things are cached. Then you get a full TCP handshake (since TFO doesn't work for the first connection), a full TLS handshake and then you get to roundtrip your request(s).
1) Drop the web font if at all possible. If not, serve it from your domain to avoid DNS query and new TCP connection. For extra points, subset it to your content's character set.
2) Consolidate your CSS and JS files into one per type and minify it. For extra points, inline the critical CSS needed to show the important content of the page directly into the head.
3) Move your script tags to the end of the body to avoid blocking rendering, or inline it if it is absolutely needed to be there before the page loads and is not too big.
4) That web font loader script is not necessary at all.
5) You might get a smaller size out of those buttons as SVG.
This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.