First the answer to your direct question, but read on to get a probable fix to your problem.
Your connection to Google almost certainly doesn't have a very similar path as other sites. Faster or slower or whatever is incidental, but mostly it's different. Google has an open peering policy, a content appliance program, nodes, probably almost every public internet exchange, and lots of transit connections; in a lot of places, your traffic will go over your provider's local network and then to google equipment directly. Chances are you're connecting to a server that's physically and network close to you with low latency.
As of right now, HN is just a single host (with a failover host?) sitting in San Diego? in a small hosting company's facilities. They peer at public exchanges in Los Angeles and Phoenix and have no content appliances etc. If you're not in the region, your traffic is going over transit, which may be congested if your ISP is underprovisioned, and anyway is going to have higher latency.
Also, because Google and YouTube are more or less essential to the modern internet experience, if they don't work, your ISP is going to get a lot of calls, so they check and make sure they work. HN, not so much.
So, now that your question is answered... how to fix it. Most likely, all of that stuff, while true, isn't the problem. In my (not so) humble opinion, you're probably having an MTU issue. If you're not familiar with MTU issues, the basic thing is every network connection has a maximum packet size (Maximum Transfer Unit or MTU), and when connecting via TCP, it's common to send an option in the SYN that indicates the maximum size (MSS option), but the MTU along the path isn't really known by either side, and if either peer sends a larger MSS than the path can support, the other peer will send packets that are too large and they may be dropped. In theory, a router that drops a packet because it's too big will send an ICMP report that the packet was dropped, but they don't always send them, or they may be rate limited in sending, or the packets may not be processed when received, etc.
Google (and some other high profile sites) specifically cap the MSS they use below the ethernet standard of 1500, which allows for clients with commonly incorrect MTU settings to work without noticing anything is wrong. HN and many other sites do not.
Unfortunately, I don't know of a good MTU test site, and I haven't had time to build one, so you really have to use ping testing to confirm and work from there. Here's a windows based example of ping testing, but it should be adaptable to anything reasonable. https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-...