»
Tech Talk
»
Beyond the Basics
»
Page size in kb's
| Beyond the Basics |
|
Page size in kb's |
|
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration 
|
I know it's probably a silly question - but how large is too large for a page size? Aside from actual size - are tehre other things to take into consideration? Like script includes and style sheets - is their size, added to the rest of the page, the only consideration, or is there considerable difference in lag when loading an external reference? C |
||
| © Copyright 2001 C.G. Ward - All Rights Reserved | |||
Stephanos
since 2000-07-31
Posts 3618Statesboro, GA, USA |
I don't know very much yet about web design. But I'll offer this tid-bit I do know. A browser nestled inside of a monitor's screen size is like the readers "eyes". The visual field only goes so far, kind of like tunnel vision. If your page is so big that most people can't cover it with the average screen size (without having to continually scroll sideways for overly wide pages) then it's probably too big. 600 pixels by 800 pixels is average, though screens are getting bigger and bigger. You should take all surfers into consideration. And hey if it's a little smaller than their screen, then no harm done. 700 wide is what I'm going with in the pages I'm building. But the length is less of a consideration. Let 'em scroll! Or did I misunderstand your question entirely? Were you talking of file size? The only problem here would be making the pages take so long to load that it angers your visitors who have slower connections. DSL and cable modems should eventually make this consideration a mute point. Stephen. Stephen. [This message has been edited by Stephanos (edited 04-09-2001).] |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
Yes Stephanos, you did misunderstand - though I appreciate the effort of the answer!  I meant page size inasmuch as time loading. I somewhat agree that one day it may be a moot point... but not anytime in the immediately foreseeable future. DSL, Cable, T1, even ISDN costs more than the average Net user is willing to pay - even if they are readily available in their area which is often not the case. So - that means we're stuck focusing on modems as well. *sigh* I found a (hopefully) useful tool here: www.jimtools.com by following the "NetTools" link at the top of the page. There is a link about the middle of the page (after following the NetTools" one) self-descriptively called: "Calculate file download time estimates." How accurate it is, I can't guess. Thanks Chris |
||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Well, ya snuck a couple of questions in there, but I think you already know my answer to the first one - a page is too large is if it's any larger than necessary. Okay, it's not really as ambiguous as it sounds. The key is to determine the purpose of the page. If someone clicks on a link to play a game or grab a pic of Britney, they've already prepared themselves to wait a little while. They are much less likely to wait if they expect to read a poem or story. More important, from a design standpoint, is determining your purpose for sending them to a page. If you want them to sign up for a newsletter, you don't want to distract them with a slow loading page. Pretty obvious. Less obviously, you want your entrance pages to load quickly, too, because your purpose there is to evoke their interest enough to stay (and click through to perhaps a more slowly loading page). One entrance page, of course, is your domain's index.htm page, and it's without question the most important page on your site. So much so, that it's worth spending hours trying cut a byte here and a byte there. But your main page isn't necessarily your only entrance page. One of the biggest problems I face with the main site is that every one of our 30-plus "category" pages is potentially an entrance page. All of them rank well in the search engines, and one is even listed in its own category in the ODP directory. And every single one of them is MUCH bigger than an entrance page should be. I've dropped the number of poems listed on each page from 100 to 80 to the current 60, and it still takes almost two minutes to fully load. So, I cheated. The only thing more important than how long a page takes to load is the perception of how long it takes to load. And the trick there is to use multiple tables and keep them fairly small, giving the visitor something to read while the page finishes loading. For example, if you go to any other UBB forum you might notice the whole thread loads at one time. One great big table. The result is that you're often staring at a blank screen for a very long time, because the browser can't show you anything until it calculates everything. Our threads load one post at a time, because each post is its own thread. Once your browser has calculated the contents of the first table, it displays it, giving you something to do while it loads and calculates subsequent tables. Similarly, those big entrance pages at the main site are broken into smaller pieces, no more than ten poem links per table. Speed is important. The perceptions of speed is far, far more important. Finally, to touch on a different aspect of your question, yes - the external JavaScript file does add more to the load time than simply its size in bytes. It also adds a "connection" time, because every single file on your page has to have its own connection from the server to your browser. And, yea, we're talking about graphical images, too. In most cases, that connection time is pretty minor. But the connection time is little different than calling up a new page, with all of the resultant overhead (look up the DNS, contact the IP, route to the server, route to the web site, find the path, find the file), and "can" take several seconds depending on Internet traffic. That's why you'll sometimes find sites with one great big graphic broken up into an image map, rather than have several "cut up" pieces of the image - they're trying to avoid the extra connection times (the disadvantage being the same as a big table - the visitor doesn't see anything until they can see everything). External JavaScript files, however, add a new variable to the old equation, a problem we don't usually have with images. When your browser hits that include command, it essentially stops everything else it was doing and waits for the entire js file to be loaded and parsed. Why? Because JavaScript can and often does write its own HTML. The browser has to assume the layout of the page is going to change and it can't display anything until it knows what the script is going to do. Often, it will seem to "hang" for several long seconds as it loads and parses the JavaScript. If it has trouble getting the connection, those seconds will stretch - and you can probably kiss that visitor goodbye. If you look at the source code at the main site, you might notice that most of the banners at the top of most pages are loading JavaScript code. But NOT the main entry page. That banner is a simple gif, usually a PSA (public service announcement), so the page can continue loading even if the visitor gets a bad connection to the ad network. It lets him know he's hit a site with banners (so I don't feel like I'm fooling him), but doesn't scare him away with a slow loading page. Or, at least, that's the intention. And I'll bet you thought it all came down to counting bytes, uh? |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
Actually, LOL, yes I did... so let me present this as an option: If you have javascript, and feel that it plays an important role - even on your main page - is it then better to not do an include, rather write it in the body of your page. That, while admittedly adding to the overall size of your document, is perhaps better than the possibility of lag from the external file. You're still dealing with the same size, et al, but you can show the site loading (by use of the tables you mentioned, which I've done. )Uhmm... what's the ODP directory? C |
||
|
Nicole Senior Member
since 1999-06-23
Posts 1835Florida |
Provided I'm not thinking of something totally off the subject: Open Directory Project "The largest human-edited directory of the web." Found here.. http://dmoz.org/ [This message has been edited by Nicole (edited 04-18-2001).] |
||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Thanks, Nicole - that is, indeed, ODP (and an important directory to crack for link popularity). Chris, whether you make your JavaScript an include or embed it is going to depend on your primary goal for that page - because both have serious disadvantages. We've already talked about the disadvantages of doing an include, so let's talk about the disadvantage of embedding it. All of the search engines are different, of course, but many of them penalize pages with JavaScript, albeit indirectly. Some count it as part of your page, thus lowering your keyword density. Some only read the first X bytes of a page, and if that is all script code you obviously won't rank very well. (Moving your code to the bottom of the page can help eliminate this latter problem, but that isn't always possible and can create new problems when it is possible.) Even those that read the whole page usually give greater importance to the top of the page. Making your JavaScript an include pretty much eliminates these SE problems. As always, there are trade-offs… |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
They sure didn't make it easy, did they? Good thing we have you 'round!  Ok - going with that, then does it matter where in your page it is in regard to the head or the body? Can you, for instance, put it in the head and have that 'penalty' reduced or eliminated? In this particular case, for me, I can get away with putting it as the very last thing on the page. Is there a place where I can find out who counts it toward you page total and who doesn't? |
||
|
|
⇧ top of page ⇧ |
|
| All times are ET (US). All dates are in Year-Month-Day format. | ||
