16

I have a rather large application which, on the admin frontend, takes a few seconds to load a page because of all the pageviews that it has to load into objects before displaying anything. Its a bit complex to explain how the system works, but a few of my other questions explains the system in great detail. The main difference between what they say and the current system is that the customer frontend no longer loads all the pageviews into objects when a customer first views the page - it simply adds the pageview to the database and creates an object in an unsynchronised list... to put it simply, when a customer views a page it no longer loads all the pageviews into objects; but the admin frontend still does.

I have been working on some admin tools on the customer frontend recently, so if an administrator clicks the description of an item in the catalogue then the right hand column will display statistics and available actions for the selected item. To do this the page which gets loaded (through $('action-container').load(bla bla bla);) into the right hand column has to loop through ALL the pageviews - this ultimately means that ALL the pageviews are loaded into objects if they haven't been already. For some reason this loads really REALLY fast. The difference in speed is only like a second on my dev site, but the live site has thousands of pageviews so the difference is quite big...

So my question is: why is it that the admin frontend loads so slowly while using $(bla).load(bla); is so fast? I mean whatever method jQuery uses, can't browsers use this method too and load pages super-fast? Obviously not as someone would've done that by now - but I am interested to know just why the difference is so big... is it just my system or is there a major difference in speed between the browser getting a page and jQuery getting a page? Do other people experience the same kind of differences?

Luuklag
  • 3,897
  • 11
  • 38
  • 57
ClarkeyBoy
  • 4,934
  • 12
  • 49
  • 64
  • Thanks. So I guess other people experience the same result then, eh? – ClarkeyBoy Jan 01 '11 at 07:18
  • 2
    I believe the biggest improvements happen on the slowest systems and it is an appearance of being faster. The page is fully functional (which is what people are waiting for) and rendered without all the content, instead of waiting for all the content and then rendering. Waiting for stuff below the fold to see the stuff above the fold is silly. – Wayne Jan 01 '11 at 07:35
  • I think I get what you mean - that the browser has to wait for the server to send the page back before it can render anything; but surely that is the same case for jQuery... otherwise the browser could render something which, in the LoadComplete event (in VB.Net), is made invisible at the last moment... What I am trying to say is that the same rules, in theory, should apply to both browsers and jQuery when sending requests / receiving responses, so jQuery should also have to wait for the page to be completed before telling the browser to render anything. – ClarkeyBoy Jan 01 '11 at 07:41
  • @Wayne: I just read the updated comment, and realise now that I did not get what you meant originally. Basically my question is asking why the div, into which the "part-page" is being loaded, is rendering the content instantly (including the stats for which it has to loop through all the pageviews), when the part-page itself takes a couple of seconds to load if I browse to it directly. It is on clicking an item in the catalogue that the div is instructed to load the stats / actions page, not on page load. – ClarkeyBoy Jan 01 '11 at 07:49
  • Hmm I *think* I may have just solved it. The initial time is usually the 1st time that I load a page after compiling the app. If I load a page, recompile the app and then click an item on the page, it takes about 2 seconds before displaying the statistics. I am not sure how to resolve this, but it seems that this may be the case. The fact that this has received so many up votes suggests that other people experience the same speed increase when using jQuery, so I will leave this question open to any answers that anyone can think of. I will investigate this issue further when I have time. – ClarkeyBoy Jan 01 '11 at 08:36
  • +1 for an excellent question. – Teekin Jan 01 '11 at 08:37
  • @Helgi: Ty. Shame I may have just solved it, and that the time difference may not exist after all (see my comment above). – ClarkeyBoy Jan 01 '11 at 08:39

3 Answers3

11

I mean whatever method jQuery uses, can't browsers use this method too and load pages super-fast?

jQuery only has available to it that which the browser provides (the DOM API). Nothing more. jQuery brings nothing extra to the table, and performs no magic tricks.

It is basically just a layer over that API, as such, it is actually slower than if you just used the API directly.

...this has received so many up votes suggests that other people experience the same speed increase when using jQuery.

You received upvotes because you praised jQuery for being fast. I think this is evidenced by the fact that none of these upvoters bothered to point out that jQuery can not somehow be faster than the browser.

If you had criticized jQuery, I'm guessing you would have been downvoted by some users.

user113716
  • 318,772
  • 63
  • 451
  • 440
  • I understand what you're saying about it being just what the browser provides, and how it cannot possibly be faster, it just seemed really odd that it was quite so fast. I think chprpipr has got the best answer, about all the images / css etc being loaded in the initial page load - it would explain why the difference is so big, more so than my last comment on the question. I thought maybe the reason for the upvotes was that other people were experiencing the time difference but couldn't explain either (hence didn't answer the question). – ClarkeyBoy Jan 01 '11 at 15:54
  • @ClarkeyBoy: Yes, I understand that. A time difference in loading will have to do with what is serving the content, and what is being served. Sounds like you're zeroing in on the issue. My point was that the premise of the question (jQuery seeming unusually fast) was not the actual cause of the difference, yet the question was heavily upvoted without bothering to point out that the premise is faulty. Take votes (both up and down) with a grain of salt. – user113716 Jan 01 '11 at 16:17
  • 2
    **downvoter: Your down vote helps prove the last sentence in my answer. Thank you. :o)** – user113716 Jan 01 '11 at 17:23
  • I don't think anyone thinks jQuery is faster than the browser. They wouldn't be a very good programmer if they thought that. I believe what the OP is asking is what optimizations does jQuery use to be fast as opposed to the speed of a naive Javascript implementation. – Nick Jan 01 '11 at 17:53
  • 1
    You state that jQuery "is actually slower" than if you just used the API directly, but I think this statement is false. It depends __how__ you use the API directly. For instance, many claim that programming in assembly will be faster than if you programmed it in C because you are using machine code directly. However, with the optimizations in compilers today, it is unlikely that someone unskilled in assembly could successfully implement their own algorithms that perform better than a good compiler. – Nick Jan 01 '11 at 17:56
  • @Nick: The question seemed to draw a pretty clear distinction between browser performance and jQuery performance. From the question: *"I mean whatever method jQuery uses, can't browsers use this method too and load pages super-fast?"* So I believe the basis of my answer is sound. Your comparison of assembly vs C/compiler to DOM API vs jQuery makes me think that you didn't really understand my answer. The point is not that a person could write poor code using the DOM API that would perform slower than equivalent jQuery code. My point is... (continued) – user113716 Jan 01 '11 at 18:22
  • ...that comparable code will always be slower when run via jQuery because of the simple expense of not running that code directly. A layer over an API always has *some* cost. This doesn't mean that it shouldn't be used. This does mean that jQuery *can't ultimately* do something faster than what the browser provides, because it is merely a layer *over* what the browser provides and ultimately uses that same code. Obviously a developer who uses the DOM API poorly will have code that doesn't perform as well as a developer who uses the API efficiently. – user113716 Jan 01 '11 at 18:26
  • ...This was never an argument against using jQuery. But I do firmly believe that the only reason the answer was upvoted was due to the fact that there are those who are willing to upvote just about anything that praises jQuery, even if the basis of that praise is misplaced. This answer simply and correctly points out that jQuery adds nothing to the browser, but rather uses what's already there. And that the assumption that jQuery can make a browser load content faster is incorrect. – user113716 Jan 01 '11 at 18:32
  • @Nick If what you say in your first comment is true then I must not be a good programmer... The reason for asking the question, however, was based purely on my observations - that a page which has a lot of processing to do rendered immediately through jQuery even though it took a while when browsing to it directly. What I overlooked - due to being incredibly tired - was the fact that the slow pages have JS, CSS and images to load too (as stated by chprpipr), whereas the "part" only has text and maybe one or two images to load. It seems that the CSS, JS and images take up most of the load time. – ClarkeyBoy Jan 01 '11 at 18:46
  • @ClarkeyBoy: Not sure why Nick made that comment about not being a good programmer. I don't know what it would have to do with your question. Anyway, one thing to keep in mind is that javascript (and I think perhaps CSS) is blocking. This means that it needs to fully download and execute before any subsequent code gets downloaded. Because of this, many people place their javascript toward the end of the page, just inside the closing `

    ` tag. This allows the CSS and HTML to download and display without being blocked by javascript. Images though do not block.

     – user113716 Jan 01 '11 at 19:04
  • Ah ok. I had heard about putting CSS at the top and JS at the bottom before, but always assumed that it meant top / bottom of the head tag (as they are supposed to go in the head tag, from what I learnt at school). Thanks for the help. I will try this later and see if it speeds up the page. I am also going through the hundreds of lines in my stylesheets at the moment and seeing what I can simplify or remove. – ClarkeyBoy Jan 01 '11 at 19:10
  • @patrick dw I'm not the downvoter, but I think it's a fallacy to say that the downvoter proves your theory against jquery supporters. This just encourages people to not downvote you even if they don't support your answer...which doesn't really answer the question in the first place. – NickAldwin Jan 01 '11 at 19:21
  • @NickAldwin: I'm not against jQuery supporters. I am one. I've answered over 1,200 jQuery-tagged questions here and spent lots of my time helping others with their issues. My answer *does indeed answer the question*. The question is how is jQuery able to load content faster than the browser. The answer is that it isn't. It doesn't solve the issue, because there isn't enough info in the question to do that. We can only speculate about the cause. – user113716 Jan 01 '11 at 19:41
  • @ClarkeyBoy: Sounds good. I'd be curious to know the result. Also, if you haven't already, look into having your code minified/obfuscated, and have your server gzip the files before it sends them. Also, check out the `YSlow` plugin for `Firefox`. It will analyze your code, and give you some great tips. – user113716 Jan 01 '11 at 19:44
  • @patrick: I am now using externally hosted minified jQuery / jQuery UI (from the jQuery or Google libraries API). As for minifying the CSS - unless I can find some tool to do it automatically on file change, I think it would be far too much effort. I'd rather spend my time removing un-needed lines from the css files and alike. I current use YSlow, Firebug, Firefox Web Developer plugin and Opera / Chromes inspect element tools (which are good for inspecting the code resulting from some jQuery execution). I don't use them that much but occasionally I may find something that I need them for. – ClarkeyBoy Jan 01 '11 at 19:58
  • 1
    @patrick dw, thanks for clearing up what you meant. That makes sense. It won't let me remove the downvote unless you edit it. – Nick Jan 01 '11 at 21:33
  • I wasn't calling anyone personally a bad programmer (I wouldn't say I'm even good at programming). What I was getting at was that it wouldn't make sense for someone to think that something written in jQuery is faster than a native browser call (as far as I'm aware, not many people think this?) – Nick Jan 01 '11 at 21:35
  • @Nick: Thank you for the offer to remove the downvote, but I think I'll leave the answer unedited for now. I knew the second half of the answer would draw a little ire from a few jQuery supporters, and I'm willing to live with the consequence of it (for a while anyway). ;o) – user113716 Jan 02 '11 at 23:08
  • @NickAldwin: You're welcome. I'd lightheartedly point out that folks are still willing to downvote me in spite of that comment above. (I just received another.) For the same reason that a person will downvote me for the content of my answer, they'll do so for the content of that comment. But that's alright. I was asking for it in a way. ;o) – user113716 Jan 02 '11 at 23:32
  • For the record, I upvoted your answer - reason being that it helped me to realise that what I thought was the case couldn't actually be the case - in actual fact jQuery could not be faster than the browser; it just appears to be because of factors such as not having to load CSS etc. This is where I wish we could create new paragraphs in these comments as, on another subject, I think Nicks point is very valid - jQuery is only slower if the programmer uses more efficient JS techniques than jQuery. With all the people behind the creation of jQuery, that is very hard to beat for the vast majority. – ClarkeyBoy Jan 03 '11 at 07:03
  • @Nick: No worries, no offence taken. As I said above, it just *appeared* to be faster because of other factors such as lack of CSS / JS and other resources. – ClarkeyBoy Jan 03 '11 at 07:06
  • @ClarkyeBoy: Thanks. Yeah jQuery will utilize some good technique in their code on one hand. On the other hand, there are methods that are designed to accommodate a wide array of uses instead of one narrow one, and must do more work to accomplish that. But any performance loss is usually pretty small and is almost always worth it. Still, I do highly recommend that people eventually become familiar with the DOM API. It isn't nearly as bad as people sometimes make it out to be, and much of it is fully browser compatible. Best of luck! :o) – user113716 Jan 03 '11 at 14:42
8

Facebook has done a lot of research into this area (loading pages in parts by Javascript rather than all at once).

See their "BigPipe" technology explained here: http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919

Jamie
  • 566
  • 4
  • 7
2

Without seeing some code, its hard to speculate but I suspect if you were to run your tests in Firefox/Firebug or IE/Fiddler, you would see many http connections being opened when you browse to each "part-page" directly. When you load each "part-page" using jQuery, you're only loading the "part-page" content and not any CSS, JS or image files.

chprpipr
  • 2,039
  • 16
  • 17
  • 1
    If on the same host, it is still one connection. Didn't you mean: 'requests are made' instead of 'connections are opened?' –  Jan 01 '11 at 11:24
  • @chprpipr: This could easily be a major part of it - I mean there are 4 stylesheets (one of which is huge) along with 2 jQuery files which are loaded when the original page loads. These are also used to style the parts without reloading the css / jQuery. Thanks for pointing this out. I don't know how I didn't think of this - its kind of obvious now I think about it! – ClarkeyBoy Jan 01 '11 at 15:37
  • @ClarkeyBoy: You'll want to make sure that those files are caching correctly. Also, if you haven't already, you might look into minification and compression options. I mostly work with .NET lately and am a big fan of SquishIt. – chprpipr Jan 02 '11 at 22:50
  • I now see that @patrick_dw already suggested this. I can confirm that SquishIt handles the tedious work as it serves individual files while in debug mode and "compiles" the code when in production mode. – chprpipr Jan 02 '11 at 22:56
  • I suppose every time I change a stylesheet I would have to "resquishit", wouldn't I? If thats the case then I will just compress them for live, not test or dev unless I am purely trying to decrease load time. I have to say it is like 80% better than it was a few days ago, since I have stopped the customer frontend from loading all the pageviews into objects before loading the page. Next thing to do, to speed up the admin backend, may be to put the pageview list into a "part" and load that using jQuery after the page has loaded. – ClarkeyBoy Jan 03 '11 at 08:31
  • Nope. Once you set it up you never have to worry about "resquishing" anything. It handles all that based on if you're in debug/development mode or production mode. It also generates squished files with unique filenames so that when you rebuild the site, old cached files don't trip you up. There's nothing worse than having to ask an angry/confused client to empty their browser cache. – chprpipr Jan 03 '11 at 17:26
  • Ok I am not sure I get what you mean, and don't have the time to try it out... so you're saying that if you have a file linked to customer.css then it may rename the file to customer_04-01-11-17-15.css..? If so then the file would be linked to customer.css still, not the new file. And I personally do not use debug mode unless I am really **really** stuck - that is, if I have spent 2 or more days trying to solve a problem, reason being that debug mode is **so** slow. How would this affect how the application (SquishIt) operates? – ClarkeyBoy Jan 04 '11 at 17:18
  • If in production mode, for example, file1.css, file2.css & file3.css would be combined and minified into cssFiles_YYYYMMDD.css and a single is placed in your code. If you make changes to one or more of those files, the SquishIt combines and minifies the latest files into a new file with a new unique name and updates the single link on the page. All of the tedious work is handles for you. – chprpipr Jan 04 '11 at 17:57
  • I am guessing that it matters that I add the stylesheets dynamically, in that case. i.e. in VB.Net I add them from the code behind... If it does matter then I am done for. It also adds different ones based on the browser and which frontend the user is in (customer or admin). – ClarkeyBoy Jan 05 '11 at 02:23