CODEWITHSUNDEEP
javascripthtml
replicant
replicant

Reputation: 329

Are multiple inline scripts slower than one conjoined inline script?

Multiple inline scripts:

<script type="text/javascript">/* some codeblock 1 */</script>
<script type="text/javascript">/* some codeblock 2 */</script>
<script type="text/javascript">/* some codeblock 3 */</script>

Single conjoined inline script:

<script type="text/javascript">
    /* some codeblock 1 */
    /* some codeblock 2 */
    /* some codeblock 3 */
</script>

are multiple inline scripts slower?

Upvotes: 1

Views: 266

Answers (3)

Jim Davis
Jim Davis

Reputation: 1230

Can't see any way that it could be measurable.

The parsers of modern browsers are blazingly fast - they're essentially sorting engines. This block goes to the HTML engine, this block to the CSS engine and this block to the JavaScript engine - those engines might take some time to do their thing, but getting the blocks to the right place isn't a performance issue at all.

The performance hit in downloading even a small page is going to be world's larger than the performance hit of collecting the code blocks and seeing them off to their engine.

Additionally JavaScript (and many other interperated languages) are run through a pre-processor that converts them to machine code as they're being loaded and run. There's probably a more fashionable name now (probably has "cloud" in it) but it used to be called "Just-in-Time Compilation" (JIT).

It's all very tangled but basically as the page is loading it just sends all the script it finds to this JIT engine. This guy collects the code, optimizes it and stores it in memory and passes anything that needs to run immediately off to the execution engine. As things run and get added it tries it's damnedest to streamline things as much as possible.

So, for code that's delayed (functions to be called later for example) the number of blocks won't matter at all. The JIT compiler is going to create in-memory optimized code that ignores the block structure anyway. For inline code that runs immedidately when encountered it doesn't really matter either because the parser that engages the script engine is so fast that you'd never be able to see a difference in any reasonable case.

That said you might be able to to build a test case that might show a difference. But I suspect that you'd need to head into the thousands (or tens of thousands) of blocks range before you'd see a measurable difference. At that point other variables - like file size (each new script block adds about 40 bytes to the file size) and render time - will become massively impacting so you may actually never be able to see a difference.

Bottom line: write clean, documented, logical code and forget about the compiler underneath. That's going to save you actual time and money rather than give you fractional, unnoticable performance boosts.

Upvotes: 1

LetterEh
LetterEh

Reputation: 26696

If you're talking abut writing the code in the actual HTML, rather than loading external JS then the answer is that it really doesn't matter.

...if browsers try to handle requests at 60fps for visual stimulus, changing as needed... ...then the difference of a few microseconds isn't going to have a large impact.

On really old browsers, if you tried to write really a lot of code (perhaps thousands of lines per tag, or tens of thousands of lines per tag), then having multiples might make a noticeable difference... ...but having a single element would still be stupid-slow in that case.

Upvotes: 2

Den T
Den T

Reputation: 157

I guess single conjoined inline script is slightly faster

Upvotes: 0

Related Questions