How pages render in 1999.io
Friday, January 15, 2016 by Dave Winer

Today I made it so the story pages here load quite a bit faster.  

For those who are interested in web technology I'd like to explain what happened. If you don't care, please hit the Back button. ;-)

Pages on Scripting News have come in all flavors of dynamic and static. Static pages of course load really fast, and dynamic pages can load slowly esp if there's a heavy load on the server, or some table gets very big, or whatever. Dynamic pages are less reliable, so in recent iterations I've been going fully static.

But there's a feature in Facebook and Twitter that I really like, when you load something, if it changes while the user is reading it, it updates on the user's screen. There's a bit of background communication going on with the server, so the server can tell the page "Hey here's some new stuff, you can show it to the user." Or something like that.

I wanted something slightly different here -- liveblogging. 

So if you have the page open and I update the post, you have to do nothing to see the updated version. No flicker, no scrolling, it's sometimes so subtle you don't even see it. I thought it would be possible to have the live features be more human-friendly. And it works, if you happen to be reading while I am editing, you should see it change. Thanks to the miracle of WebSockets, a very rational technology that works well in the mainstream browsers of 2016. It's good. 

So the natural way to do things when someone loads the page is to send a websocket call to the server, let it send back the update and then show it to the user. But it's a bit more complicated. At startup with all the caches empty, it also has to make requests to the server to get info about the author and to tell it to load the author's chatlog before we make a call that loads the content. Some of that can be optimized too. The server is very fast, but there's enough of a delay in starting up that you feel it when you load the page.

Luckily there's an object baked into the page called the pagetable, and in it there's an object called item, and it has a full, but possibly old, copy of the message that we're going to get from the server. It's a snapshot taken the last time the page was statically rendered. It really can't be too old, and anyway the first thing we do after showing it to the reader is do the dance with the server to set up the socket so it can inform us of updates which it will do as soon as we've properly shaken hands. 

So it's static, and dynamic. That's what I wanted: the benefits of both approaches without the costs.

It also accounts for the possibility of a server outage or it outright disappears. The static version will be what you see. And there's an invisible-to-the-reader rendering in the page just for Google et al to index. 

So the net effect is we get all the benefits, reliability and performance of a static page, and the best-in-the-industry live connection. Even Facebook doesn't update stories in realtime when they change, and as you know you can't even edit Twitter posts.