Slowness of Google Docs

Don’t get me wrong. I love Google Docs.

But it’s slowness drives me crazy.

When I start opening a Doc it goes through several frustrating phases (with very rough times):

  1. blank page – 5 seconds
  2. content (which can’t be edited) – another 10 seconds
  3. rendering table of contents in sidemenu – another 3 seconds

The frustrating stages are 2 and 3 where it feels as if I should be able to edit content but can’t.

In total, it’s almost 20 seconds before the content can be edited. What makes it even more frustrating is that during phase 2 it appears as if the content can be edited but can’t until various other things have loaded.

Software and cascading problems

One of my pet peeves about software is how problems seem to cascade. E.g. I have an app I built which is on the App Store. I temporarily took it off the market as a supplier who provides some of the data was experiencing problems. They resolved the issue so I decided to put the app back on the market. I have a bookmark to the iTunes Connect dashboard. The dashboard needs a password. To avoid having to remember all these passwords or write them down somewhere I store in another piece of software called 1Password.

However, I got an error saying “Browser could not be verified”.

I Google’d the problem but the page ( ) was loading extremely slowly. When the page finally loaded it suggested restarting my Mac.

Various software updates took advantage of the system restart so it was around 10 minutes before I could connect to iTunes Connect.

Now, that error had gone but clicking on the password entry didn’t fill out the email and password as usual. I had to manually copy it from 1Password and paste it in.

Finally, once in the iTunes Connect dashboard, I had to figure out how to put the app back on sale. The Dashboard looked like this:

  1.  a menu at the top:

App Store Features TestFlight Activity App AnalyticsSales and Trends

None of which seemed relevant.

2.  a sidebar with:


App Information

Pricing and Availability


3.6.0 Developer Removed From Sale


1.0 Prepare for Submission


3. a content block with this at the top:

Developer Removed From Sale

Nothing here seemed particularly clear about how you put the app back on the market.

So, some more Google’ing.

The first link was to Apple’s documentation:

The problem with this documentation is that it goes on for literally dozens of pages. I really wanted an answer that didn’t involve half an hour of wading through vast reams of unrelated text.

So I visited the second link on an iPhone development forum:

which went something like this:

Question: Hi guys, just a quick question, when I remove the app from sale (developer removed from sale) it is still in my “menage apps screen”, how can I put it back on sale? Does it need to go through a review process again?

Answer: No, just turn it on again by selecting which country you want it in

Not terribly useful as it didn’t tell you how you select countries.

Back to the Apple docs.

Scanning through it I found, around 3/4 of the way down the document (around 11 pages of text) I finally found the information I needed, confusingly under Removing an App from Sale.

You have to go into Pricing and Availability, select “Available in all territories” and Save.

This was a pretty trivial example but shows off some of the complexity that can accumulate. A simple thing like ticking a box took around an hour to do.

What happens when a browser requests a web page like

  1. you enter
  2. your browser will do a DNS look up for the IP address of this URL. This process is:
    1. check browser cache – the OS does not tell the browser the TTL for each DNS record so the browser caches DNS records itself for 2 – 30 minutes
    2. check OS cache – e.g. gethostbyname on the Mac and Windows
    3. check router cache
    4. check ISP DNS cache
    5. recursive search
      1. root nameserver
      2. .com nameserver
      3. nameserver
  3. browser sends a GET HTTP request to the web server along with other headers. e.g.
    1. Host:
    2. Accept: types of responses it will accept
    3. Connection: TCP connection
    4. Cookie:
  4.  server probably responds with a 301 Permanent redirect to
  5. browser sends out another request to
  6.  server handles the request
    1. i.e. it reads the request, any parameters and cookies
  7. server sends back an HTML response which consists of
    1. HTTP/1.1 200 OK header
    2. Cache-Control:
    3. Expires:
    4. Pragma:
    5. Content-Encoding: gzip
    6. Content-Type: text/html; charset=utf-8
    7. Date:
    8. Byte blob which the Content-Encoding section tells you is gzip’d.
    9. Decompress the blob to get the HTML
  8. Browser renders the HTML as it starts receiving it
  9. Browser sends requests for objects embedded in the HTML. E.g.
    1. images
    2. CSS
    3. JS
  10. Browser sends further AJAX

See  Hypertext Transfer Protocol — HTTP/1.1 (RFC 2616):