Source links on cs.opensource.google are slow (links for stdlib on pkg.go.dev)

286 views
Skip to first unread message

ben...@gmail.com

unread,
Aug 25, 2021, 9:11:59 PM8/25/21
to golang-nuts
With the switch to pkg.go.dev (which in itself I quite like after getting used to it), the view-source links also changed from the golang.org source viewer, which was fast, to cs.opensource.google, which is rather slow.

For example, here is the code I've been looking at just now, compared to GitHub.com:

* https://cs.opensource.google/go/go/+/refs/tags/go1.17:src/os/exec/exec.go;l=189 -- this loads in 4-5 seconds for me, with two client-side "loading..." states shown
* https://github.com/golang/go/blob/go1.17/src/os/exec/exec.go#L189 -- this loads in 1-1.5 seconds, with no loading states

I believe GitHub is faster because it serves the code in the initial HTML response, whereas cs.opensource.google serves a bunch of JavaScript that (after a couple of steps) loads the source. I believe the golang.org source used the GitHub approach -- at least, it was similar speed to GitHub so I never noticed this or needed to check.

I'm located in New Zealand, so it is no doubt further away from their origin servers than Google employees testing this stuff. (I asked a colleague from Australia, and he gets ~5s for cs.opensource, ~1s for GitHub.) I have a fast internet connection. The tests above are in the latest Firefox under Linux, but I've also tested using Chromium and get very similar results (on my first go in Chromium, which didn't have any cached, it was ~8s for cs.opensource.google and ~2s for GitHub, after that it was similar to the above).

It's frustrating, because most 3rd party packages (hosted on GitHub) get the faster GitHub view-source experience, but the core stdlib gets the slow experience!

Someone has suggested moving to GitHub in this issue: https://github.com/golang/go/issues/47202 ... however, it was more about the UI and got closed with "if you have suggestions for cs.opensource.google, use the Send Feedback button". I submitted feedback using that button, though I doubt that'll cause anyone to do a major rewrite of their architecture.

It seems to me that pages taking 4x as long to load is a series regression that hurts usability, at the very least outside the U.S. I use those stdlib source links a lot, and it's a bit of a killjoy to wait 4-8s each time.

I'm happy to open a new issue on this, but thought I'd see if others have input first.

-Ben

Dan Kortschak

unread,
Aug 25, 2021, 10:37:11 PM8/25/21
to golan...@googlegroups.com
This has been my experience too (in .au). It is quite frustrating.

Dan



Kurtis Rader

unread,
Aug 25, 2021, 10:53:38 PM8/25/21
to ben...@gmail.com, golang-nuts
I'm in Santa Clara, CA. Just a handful of miles away from Google headquarters. Your two links exhibit orders of magnitude differences in load time for me. Using the Chrome browser developer tools display shows several errors that are likely the cause of the difference in load time; at least for me. For example:

Access to XMLHttpRequest at 'https://play.google.com/log' from origin 'https://cs.opensource.google' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'http://play.google.com' that is not equal to the supplied origin.
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Ben Hoyt

unread,
Aug 25, 2021, 11:01:00 PM8/25/21
to Kurtis Rader, golang-nuts
> I'm in Santa Clara, CA. Just a handful of miles away from Google headquarters.
> Your two links exhibit orders of magnitude differences in load time for me.

I presume you mean orders of magnitude, with cs.opensource being slower? What are the actual figures you get?

Just for the record, for my timings of ~1s vs ~4s, I was doing very rough timing just counting seconds till the source code content was visible ... I didn't need to do anything more accurate as they were so far apart.

> Access to XMLHttpRequest at 'https://play.google.com/log' from origin 'https://cs.opensource.google'

Ah, great, our IP addresses and traffic data's going into Google's analytics engine, too. :-)

-Ben

Kurtis Rader

unread,
Aug 25, 2021, 11:03:11 PM8/25/21
to Ben Hoyt, golang-nuts
Yes, exactly. 

Robert Engels

unread,
Aug 25, 2021, 11:27:16 PM8/25/21
to Ben Hoyt, Kurtis Rader, golang-nuts
Every site you access probably uses Google analytics or something similar. 

It is often used to understand usage patterns, site design, etc. 


On Aug 25, 2021, at 10:00 PM, Ben Hoyt <ben...@gmail.com> wrote:


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAL9jXCGQExy_udnCCtrgvh5ZPQUWWL8HA%3D8uG9AjCzmR1VZitA%40mail.gmail.com.

Ben Hoyt

unread,
Aug 25, 2021, 11:29:09 PM8/25/21
to Robert Engels, Kurtis Rader, golang-nuts
Every site you access probably uses Google analytics or something similar. 

It is often used to understand usage patterns, site design, etc.

Yeah, fair enough. I shouldn't have side-tracked my own discussion. :-)

-Ben

ben...@gmail.com

unread,
Oct 3, 2021, 4:05:16 PM10/3/21
to golang-nuts
For the record, I've just opened https://github.com/golang/go/issues/48752 to track this.
Reply all
Reply to author
Forward
0 new messages