document.getElementById vs document.write?

Forum Moderators: open

Message Too Old, No Replies

document.getElementById vs document.write?

ewwatson

10:38 am on Nov 12, 2012 (gmt 0)

I'm trying to get rid of a document.write statement because I read that it can slow a site. It's the first thing on my page because I need it to show first. jquery methods and like are not fast enough. So does...

document.getElementById("loading").innerHTML = "Loading...";

Suffer from the same performance problems of document.write?

lucy24

11:48 am on Nov 12, 2012 (gmt 0)

It's less about "how long" than about "when". document.write has to be done before the page finishes loading. (This is one of those mistakes nobody makes more than once ;)) innerHTML can be popped in at any time.

Crude analogy: think of a page filled with images that either have or don't have "height" and "width" statements. If they're missing, the browser has to load up everything before it can figure out where things go, and has to keep redrawing the page. If the height and width are in the HTML, the browser can shove in placeholder boxes and slowly fill them in while you're reading the page.

But if nothing else can happen until the images show up-- still in analogy here-- then it doesn't really matter.

This is assuming you're talking about explicit visible text. If you're changing styles or any other behind-the-scenes action, there are other ways to do it.

And the biggest assumption of all: Does it have to be javascript? That is: Is the text based on information about the user-- and in particular is it based on information that won't come through in an ordinary User-Agent string (which is visible to the server before the page even starts to load)?

ewwatson

12:22 pm on Nov 12, 2012 (gmt 0)

Thank you! But I had a little trouble following your analogy. So getElementById is sort of like asynchronous loading? It can load along with the rest of the page? Whereas doc.write the browser has to freeze - render js - then move on to the rest. Is that correct?

The text is added only when js is on. When js is off I dont want it there. I have 6 other ways to do this, this and oc.write though are the only ones I can keep my js at the bottom and have this js loaded text show up fast. And not be regular html text because google doesnt need to see this.

daveVk

12:29 pm on Nov 12, 2012 (gmt 0)

If it must be done prior to page onload use write() after onload use getElementById or similar.

Dom access prior to load may fail as the Dom if not fully loaded.

ewwatson

12:44 pm on Nov 12, 2012 (gmt 0)

well the getElementById shows up just as fast. the html called is above the script. So its dom is ready i imagine

Someone please just tell me which method is faster and/or prefered. These are my only two available methods that much I know.

lucy24

1:04 pm on Nov 12, 2012 (gmt 0)

If you try both ways with a long chunk of text, you can see where the difference happens. Watch for the point when page loading seems to freeze. I think technically innerHTML takes longer, but it happens later so it doesn't interfere as much.

And of course document.write is risky because if there's a glitch and it doesn't write while the doc is still loading, then your whole document will disappear :) Better to save it for things like popups that don't have any other text to collide with.

Uhm, you do realize, don't you, that the googlebot has become awfully good at executing javascript? Not just reading it, but seeing what it does. So if you need* to hide something from the googlebot, put it in a function in a separate file, and 403 prevent robots from even looking at it.

* For, ahem, a given definition of "need".

Fotiman

2:32 pm on Nov 13, 2012 (gmt 0)

If it must be done prior to page onload use write() after onload use getElementById or similar.

That is bad advice. Avoid document.write at all times. It's considered bad practice, and there are cleaner alternatives.

document.write leads to poor coding habits, like mixing behavior code with content. In your case, you might consider doing something like this:

Design for the base case (JavaScript disabled) and treat this for what it is... progressive enhancement. For example, give your <html> element a class like "no-js", then a script early in your <head> element can change that class value if JavaScript is enabled. Then you can define your presentation such that if there is no JavaScript, the "loading" message is never shown, else it is:

.no-js #loading { display: none; }

Then within your content, you include it:

<div id="loading">Loading...</div>

Check out Modernizr [modernizr.com]

swa66

5:37 pm on Nov 13, 2012 (gmt 0)

I'm with Fotiman: document.write is "evil".

In polyglot html5 (xhtml served as xml to all but IE) document.write isn't even supposed to work any longer ...

daveVk

12:05 am on Nov 14, 2012 (gmt 0)

The rules on what DOM operations are safe prior to onload are unclear to me.

Conservative practice is to wait for onload.

Some operations clearly work prior to onload and are a better alternative to document.write().

With practice of putting js at end of body (or even higher), is waiting for onload obsolete ?

lucy24

2:02 am on Nov 14, 2012 (gmt 0)

In some situations it will apparently wait for other stuff to load, whether you want it to or not.

:: off to paw through browser history, because I was reading about this less than 24 hours ago, and it came with colorful diagrams and everything ::

It's somewhere in the inmost depths of google Developers, if that rings any bells with anyone.

Fotiman

3:14 pm on Nov 14, 2012 (gmt 0)

With practice of putting js at end of body (or even higher), is waiting for onload obsolete ?

That's a good question, which probably deserves it's own thread. Here's my short answer:

Putting scripts just before the closing </body> tag is almost equivalent to waiting for the onload event, but assets like images might not be fully loaded yet. In most cases, waiting for all the assets is not useful. As far as DOM manipulation, any elements that have been defined prior to the scripts just before the closing </body> will be accessible via the DOM when those scripts run.

lucy24

8:22 pm on Nov 14, 2012 (gmt 0)

assets like images might not be fully loaded yet

... which, in turn, is the big argument in favor of including height and width declarations: it then doesn't matter if the image has been physically loaded.

This is what I was trying to find yesterday:
https://developers.google.com/speed/docs/best-practices/rtt#PutStylesBeforeScripts
(intentionally de-linked to preserve the fragment, which leads straight to the pretty pictures). This in turn is immediately followed by the "avoid document.write" bit.

:: wandering off to find out what the ### a "speculative parser" is ::

daveVk

10:58 pm on Nov 14, 2012 (gmt 0)

The 'almost equivalent' concept is a good. The question then becomes what is safe in the red zone (prior to onload or 'almost onload').

Red zone DOM access is questionable.

Red zone document.write(), probably works but evil.

Red zone code should be avoided ? ( I do )

Red zone code has legitimate uses ?

Fotiman

12:24 am on Nov 15, 2012 (gmt 0)

What is safe?
Any DOM element that was defined prior to the script.

What is not safe?
Any DOM element that was defined after the script (or elements that are being loaded asynchronously, which, for the record, are also not safe with the document onload event).

ewwatson

9:29 pm on Nov 15, 2012 (gmt 0)

".no-js #loading { display: none; }

Then within your content, you include it:

<div id="loading">Loading...</div> "

Hey guys. Ya thats how I originally did it give or take. But then I noticed google reading my Loading... text as the first word. Dont want that. So I did this..,

In my head I have this on each page. document.documentElement.className = 'js';

At the bottom of my page I have this on each page.
document.getElementById("loading").innerHTML = "Loading...";

In my css I have #loading {display:none} html.js #loading {display:block}

Works perfect. Loads instantly - first thing on the page. Google may still parse the js but now it's at the bottom and its js so the bot dont care.