What would i be better off having a lengthier Javascript or a lengthier HTML. Few things- 1. I don't care about the SEO ratings. 2. I do care about the speed of the site. 3. I do care about the functionality of the web site.

Basically my question for the core coders- Whats better -

<div> Blah blah blah blah </div>

or

document.getElementById("blah").innerHTML = "Blah blah blah blah"

? Any extra knowledge is always wele too :). Thank You.

What would i be better off having a lengthier Javascript or a lengthier HTML. Few things- 1. I don't care about the SEO ratings. 2. I do care about the speed of the site. 3. I do care about the functionality of the web site.

Basically my question for the core coders- Whats better -

<div> Blah blah blah blah </div>

or

document.getElementById("blah").innerHTML = "Blah blah blah blah"

? Any extra knowledge is always wele too :). Thank You.

• javascript
• html
• ajax

• 1 4 spaces before a line formats it as code. ctr-k for a selection. – Peter Ajtai Commented Oct 7, 2010 at 19:22

8 Answers 8

Having the browser render plain HTML will always be faster than having to load JavaScript, wait for the DOM to be ready, and then use JavaScript to manipulate the DOM.

Even if you ignore the fact that the browser has to do more work when manipulating the DOM via Javascript, just think about which is going take longer to download:

30 Characters:

<div>Blah Blah Blah Blah</div>

or 50+ Characters (too lazy to count):

<script>
    document.getElementById("blah").innerHTML = "Blah Blah Blah Blah";
</script>

So by going the JavaScript route you're both downloading more content from the server and asking the browser to do more work to render the page.

As the others have said, pure HTML will be faster to load. However, depending on what you are actually trying to acplish the decision/answer could be a little trickier.

For instance, you could have just a basic html skeleton with a content placeholder that then loads the actual data via an ajax call. Since the initial rendering will happen very quickly the user perception would be that the site loaded very quickly. The actual/overall time will be longer but since the bast site renders quickly the tradeoff could be worth it.

The HTML will be faster, because javascript requires extra bytes to be downloaded to the browser to add the text to an element. Besides, Javascript requires extra scripting and functions overhead, which will not be much, but for large sites, it will be slower.

HTML is obviously going to be faster for the given example. There's no logic involved in the HTML portion, and Javascript would have to perform operations to produce the same result. It's also more characters and then marginally more bandwidth.

The reasons you will want to use Javascript will render the question moot. You will use Javascript for things that couldn't be done in your initial HTML output.

While Justin Niessner's answer is basically right, I would add that the actual speed of loading a site as well as the user's perception of a site's speed can be influenced by a lot of factors. Consider:

• Amount of data transferred from the server to the browser.
• Number of HTTP requests for a single page to load.
• Overhead caused by whitespace, non-minified JavaScripts, non-minified CSS styles.
• Unoptimized images.
• Dynamic vs. static construction of the page.
• Placing presentation logic into the server vs. into the browser.

etc.

the HTML would be faster if for no other reason than that you still would have to send the exact number of bytes for the characters you want to display PLUS the extra characters for the javascript to turn around and render that back into the page. Now if you're planning to use javascript to later add elements to the page via AJAX, then it's better to send the data as JSON and assign it to html elements.

HTML will always render faster.

Potential problems of using JavaScript as you described:

1. JavaScript takes time to execute.
2. You have to wait for the element to get created before you can access it with JavaScript.
3. If the JavaScript is in a separate file it'll be an extra HTTP transfer back and forth to the server.
4. If the user has JavaScript turned off he won't see it at all.
5. The JavaScript is code is also slightly larger so it'll again take more time to transfer.
6. There's also accessibility issues (screen-readers may have trouble).
7. innerHTML is not standard JavaScript so some browsers may not execute it correctly.

<div> Blah blah blah blah </div>

Is faster, since the other code is inplete, it has to be:

$(document).ready(function() {   // Using jQuery here, since creating a pure
                                 // JS DOM ready is a pain.
                                 // window.onload is fired later.
    document.getElementById("blah").innerHTML = "Blah blah blah blah";
}

So, by the time the JS goes to work, the DOM is ready, and that essentially means the text is rendered.

and of course it's absolutely no contest if you use:

window.onload = function() { ...

It would be interesting to see when it's faster to draw icons in SVG than loading them as an image from the server.... that's a pletely different question though with many variables.