Browser slow

This page exists to aid IT professionals who may be attempting to investigate an instance of a slow connection to the UCSC Genome Browser (genome.ucsc.edu). The UCSC Genome Browser also has mirrors in Asia (genome-asia.ucsc.edu) and Europe (genome-euro.ucsc.edu) that can be used to compare performance behavior.

If you are not an IT professional and have found this page, see the bottom checklist for some actions an average user can take to examine browser speed.

Background explaining how the Browser works

There are various factors that could make the browser appear to have slow behavior. Below is a listing of how the Browser transmits data, followed by suggested ways to test and troubleshoot performance with verification steps.

The function of the browser consists of the following activities:

1. Your device's web browser requests the URL, for instance: https://genome.ucsc.edu/cgi-bin/hgTracks?measureTiming=1
2. The machine at UCSC, the Apache WEB server, receives the request
3. Apache runs the requested program, hgTracks in the example link, within the UCSC system
4. The output of that program is returned via the Apache connection as HTML text to your device's web browser
5. As your web browser receives that HTML text it interprets it to begin displaying the content
6. There are a number of URL links in that HTML text (on the order of about 65 links) to further online materials
7. Most of those links are static content that your web browser already has in its cache
8. There are approximately 5 links that are dynamic content, your web browser requests those files from UCSC
9. After all the files are received by your web browser, the page display is complete in your device's web browser

By adding to the URL an additional measureTiming=1 argument in the initial request to UCSC, the hgTracks process will report millisecond timing for the various operations that take place at UCSC. The final measurement reported: Overall total time seen in the bottom of page is the total time spent in processing at UCSC. All operations are complete at UCSC in that displayed time. Any additional time observed beyond that "Overall total time" is due to network transfer timing for the HTML content and additional files specified in the HTML code. The total amount of data transferred is typically less than 2Mb of data, and most of that is static content that does not transfer when it is already in your web browser cache. Typical dynamic content that does transfer is on the order of 300Kb for the HTML text and 300Kb for the graphic images. These final dynamic content sizes depend upon what tracks are set to display in the browser view (for instance, more displayed tracks will translate to a modestly larger HTML file and larger graphic image file).

The following are some troubleshooting steps to verify performance.

Check your network connection

Verify browser address can be found, unix command: host genome.ucsc.edu

$ host genome.ucsc.edu
genome.ucsc.edu is an alias for genome.soe.ucsc.edu.
genome.soe.ucsc.edu has address 128.114.119.131
genome.soe.ucsc.edu has address 128.114.119.132

Verify network path is available to the browser: ping -c 3 genome.ucsc.edu

$ ping -c 3 genome.ucsc.edu
PING genome.soe.ucsc.edu (128.114.119.131) 56(84) bytes of data.
64 bytes from hgw1.soe.ucsc.edu (128.114.119.131): icmp_seq=1 ttl=43 time=170 ms
64 bytes from hgw1.soe.ucsc.edu (128.114.119.131): icmp_seq=2 ttl=43 time=170 ms
64 bytes from hgw1.soe.ucsc.edu (128.114.119.131): icmp_seq=3 ttl=43 time=170 ms

--- genome.soe.ucsc.edu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 170.361/170.370/170.378/0.007 ms

Verify browser is alive and well

 time wget --user-agent=browserAliveTest -O- https://genome.ucsc.edu/cgi-bin/hgTracks?measureTiming=1 2>&1 | grep Overall
<span class='timing'>Overall total time: 526 millis<br /></span>

real    0m1.245s
user    0m0.021s
sys     0m0.019s

Note the Overall total time: 526 millis is the total run time of the hgTracks CGI binary

The real 0m1.2345s is the total run time of the wget command including the transmission of the html text from the hgTracks operation. This test can also be used on the http connection to see if it is any different from the https connection:

time wget --user-agent=browserAliveTest -O- http://genome.ucsc.edu/cgi-bin/hgTracks?measureTiming=1 2>&1 | grep Overall
<span class='timing'>Overall total time: 439 millis<br /></span>

real    0m0.959s
user    0m0.003s
sys     0m0.012s

verify browser performance similar to web browser access

The simple wget test above only transmits the single top-level content of the html page returned from hgTracks. Your web browser will use references within that page to request more files from the browser. To simulate a complete, no cache involved, transfer of all files in the browser page, go to a work directory where the wget command can create a hierarchy of files. For example:

$ cd /dev/shm
$ time wget --user-agent=browserFullPageTest \
-o browser.wget.log \
--wait=0 \
--execute="robots=off" \
--no-cookies \
--timestamping \
--level=1 \
--convert-links \
--no-parent \
--page-requisites \
--adjust-extension \
--max-redirect=0 \
"https://genome.ucsc.edu/cgi-bin/hgTracks?measureTiming=1"

real    0m9.962s
user    0m0.074s
sys     0m0.040s

$ grep Overall genome.ucsc.edu/cgi-bin/*.html
<span class='timing'>Overall total time: 463 millis<br /></span>

Again, the Overall total time: 463 millis is the total run time of the hgTracks CGI binary, and the real 0m9.962s is the total time for the wget command to transfer everything. You will find a hierarchy of files in a newly created directory ./genome.ucsc.edu.

If this command is repeated, with the previous result available in ./genome.ucsc.edu, this will simulate (not perfectly) a web browser operation where the static content remains in cache and doesn't need to be transferred again. This isn't a perfect web browser simulation because this command does a HEAD operation on each access that it wants to determine if it can be cached. A web browser has other means of caching to avoid constant HEAD operation. It will occasionally, but not often.

The browser.wget.log file can provide clues of timing for each request to see what may be taking a long time.

Checklist for an average user

1. Check your overall internet speed, make sure it's not already slow to other websites.
2. Make sure your institution connection is not slowing the browser down for you, this sometimes happens for security reasons. Compare speeds from your home connection, or cellular connection, versus your institution to see if things improve.
3. Make sure you do not have an unusually high number of tracks set to display as that can impact speed.
4. Consider if you don't have any irreplaceable data loaded to use the "Reset All User Settings" option under the top "Genome Browser" menu. You can save a session first to return to your previous view ("My Data" menu and "My Sessions").
5. Check to see if you have a Track Hub connected in your viewing session, and examine if access to that remote Track Hub is slow. Disconnecting a slow Track Hub can improve performance.
6. Make sure your IP address is not spamming the Browser site with robot hits, abusive programmatic access will be slowed if it is from your same IP (you should see a displayed note).
7. Our site occasionally experiences a temporary server overload, so be patient if the slow-down has only been for a few minutes, it will likely return.
8. If all else fails, please contact the Mailing List with a session where you add "&measureTiming=1" to the URL so we can attempt to replicate your experience.