Current time: 07-18-2019, 06:55 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Inline JavaScript Experiment
07-09-2010, 07:25 PM (This post was last modified: 07-09-2010 07:29 PM by calumfodder.)
Post: #2
RE: Inline JavaScript Experiment
One problem with inlining is the increased page weight per page when looking across multiple pages on your site.
Having JS/CSS external allows the browser to cache JS/CSS that might be used across multiple pages. Using the inlining technique you pay the page weight penalty each time.
If the JS/CSS is specific only to that page then you have a valid argument for inlining it.
If you are serving up content to mobile users then it is also worth paying the page weight penalty as having to get many resources for a page is expensive over mobile connections.
If there is high latency, high bandwidth then inlining is best, as in mobile. If there is low latency, high bandwidth then a degree of parallelism will win over downloading one large resource.
You ask a question about "if you have to include a script that blocks other downloads"....I would ask back does it really have to block downloads? If so would it not be worth investigating redesigning the page so that it does not rely on the blocking javascript. You may be able to move to a more asynchronous model that gives a perceived performance improvement in terms of the end user experience even though the overall performance may not be improved.
Looking at your tests the results times are very similar. So similar on the repeat views section that I would consider them to be the same. It is important to take into account the margin of error produced in the results from the test platform. Whilst I don't know the margin of error for WebPagetest i would suggest that the results for the repeat views are likely to fall within it and therefore can be considered to be the same. Maybe a suggestion for aiding in the analysis of results would be the publication,by WebPagetest, of the likely margin of error for the test run?
From the looks of the js ( i had a v.brief look) you have inlined you could asynchronously load that resource using a pattern like the latest one used by google for google analytics. This should reduce the time to document complete further for your tests.

I see no reason as to why Google would be affected by the inline javascript, they heavily use inlining with mobile applications. The performance indicator they are taking into account for their ranking is the page load time (I think it is to the Onload event but I'm not sure), so if the inlined page is quicker then, all things being equal between yourself and your competitors in the other aspects of ranking, you should see your ranking improve.

Cheers
Cal
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Inline JavaScript Experiment - calumfodder - 07-09-2010 07:25 PM
RE: Inline JavaScript Experiment - pmeenan - 07-10-2010, 02:50 AM
RE: Inline JavaScript Experiment - pmeenan - 07-10-2010, 05:33 AM
RE: Inline JavaScript Experiment - pmeenan - 07-11-2010, 01:42 AM
RE: Inline JavaScript Experiment - sajal - 07-12-2010, 08:04 AM
RE: Inline JavaScript Experiment - pmeenan - 07-12-2010, 02:19 AM
RE: Inline JavaScript Experiment - jklein - 07-13-2010, 12:19 AM
RE: Inline JavaScript Experiment - jklein - 08-05-2010, 05:10 AM
RE: Inline JavaScript Experiment - pmeenan - 08-11-2010, 05:05 AM
RE: Inline JavaScript Experiment - jklein - 07-13-2010, 12:49 AM
RE: Inline JavaScript Experiment - pmeenan - 07-13-2010, 05:42 AM
RE: Inline JavaScript Experiment - pmeenan - 07-13-2010, 09:09 AM

Forum Jump:


User(s) browsing this thread: 1 Guest(s)