It is currently Thu Mar 28, 2024 11:31 pm


The forum is READ ONLY. Please direct any future discussions to our Facebook page


 Page 1 of 1 [ 6 posts ] 
Author Message
 Post subject: Javascript code
PostPosted: Fri Oct 17, 2008 9:16 pm 
Newbie
Newbie

Joined: Mon Sep 01, 2008 10:22 pm
Posts: 30
Silly question: is there a reason that you are replicating all of this javascript into each page, thus increasing said page size (and your bandwidth requirements, even accounting for compression) rather than including the javascript as a separate file? E.g., right now, you are doing this:

<script type="text/javascript" />
/* include ye olde javascript code here */
</script>


Why not do this?:
<script type="text/javascript" src="js/aatfuncs.js" ></script>


Is there something I'm missing here? I'm guessing there must be, as the second method would result in fewer requests to the server, due to client-side browser caching. The main down side is that you'd have to change the filename every time you made a change to the file, owing to some badly behaved browser caches and proxy servers.


Offline
 Profile  
 
 Post subject: Re: Javascript code
PostPosted: Fri Oct 17, 2008 10:12 pm 
Developer
Developer
User avatar

Joined: Wed Feb 19, 2003 6:07 pm
Posts: 2930
Actually this REDUCES the page size since the site and game uses zlib compression by default. Most of this applies to both the game and the web site.

The main page of the web site...

Content (encoded: 15.87 KiB / decoded: 72.39 KiB)

The encoded size is a compressed version of the HTML and that is the bandwidth used. The decoded size is the uncompressed size of the HTML that would normally be sent if compression was turned off.

If we used <script type="text/javascript" src="js/aatfuncs.js" ></script> the js file wouldn't be compressed as it would be loaded outside of the template engine.

The other reason we are doing this on the main site is because Firefox is horribly BUGGY when it comes to using loaded CSS files. Half the time it doesn't process them properly so you have a broken page. I tested this over and over again using the latest Firefox version. Opera, Safari and IE would display the site properly every time. Firefox would display a mangled page 1/4 of the time. Firefox seems to have a problem with large CSS files and CSS formatted pages.

The only way we could get Firefox to load the web site properly every time is to have the CSS included in the HTML. Yes it makes the HTML larger but with compression it is actually smaller and faster that having it loaded externally.

Some people will hate me saying this but I have come to hate Firefox almost as much as IE because it has almost as many QUIRKS and failures. I am starting to spend more time getting web pages to display properly in Firefox than IE when it comes to CSS and/or Javascript heavy pages. Now that is damned sad.



_________________
PJ's Annoyingly Useless Blog
ADOdb Lite
Template Lite
Offline
 Profile  
 
 Post subject: Re: Javascript code
PostPosted: Sat Oct 18, 2008 9:26 am 
Newbie
Newbie

Joined: Mon Sep 01, 2008 10:22 pm
Posts: 30
Panama Jack wrote:
Content (encoded: 15.87 KiB / decoded: 72.39 KiB)

The encoded size is a compressed version of the HTML and that is the bandwidth used. The decoded size is the uncompressed size of the HTML that would normally be sent if compression was turned off.


Err......yeah, I get how compression works. ;)

Panama Jack wrote:
If we used <script type="text/javascript" src="js/aatfuncs.js" ></script> the js file wouldn't be compressed as it would be loaded outside of the template engine.


That rather depends. You could have apache automatically compress the js before it gets sent. Even if you don't, though, you'd only be sending the js at most once/session, as the browser would cache it on the client side. As a result, your total bandwidth would go down even lower, and probably significantly.

Panama Jack wrote:
The other reason we are doing this on the main site is because Firefox is horribly BUGGY when it comes to using loaded CSS files. Half the time it doesn't process them properly so you have a broken page. I tested this over and over again using the latest Firefox version. Opera, Safari and IE would display the site properly every time. Firefox would display a mangled page 1/4 of the time. Firefox seems to have a problem with large CSS files and CSS formatted pages.


Really?!?! I've not encountered this before, and I've done a LOT of work with Firefox. I.E. is a pig, and Opera has an annoying quirk with how it handles the <hr> element. Other than that, I've found that if I write W3C compliant code for FF (and that includes CSS), it tends to work in Safari and Opera, and then I have to tweak the hell out of it to make it work in IE (although IE 7 is SOMEWHAT better in this regard). However, I tend to rely primarily on CSS for my effects, rather than javascript (which you seem to). That might be the key difference. Certainly, the javascript approach allows you to do some things that are hard (if not downright impossible) to do using a CSS-only approach, ESPECIALLY across multiple browsers.

I suppose the old "Your mileage may vary" adage applies here. LOL.


Offline
 Profile  
 
 Post subject: Re: Javascript code
PostPosted: Sat Oct 18, 2008 12:22 pm 
Developer
Developer
User avatar

Joined: Wed Feb 19, 2003 6:07 pm
Posts: 2930
Yes, we could enable site wide compression but there are problems with that as well. We have more than one site on the server and not all of the software is written by us. You would be surprised by how many software packages don't check for site wide zlib compression. They just check to see if the zlib library is available and start compressing. This causes some output to be compressed twice. Once by the software package and then again by the site wide compression. The user then gets garbage.

Also, if we ever had to move the site from our own server to another hosting company they probably do not offer site wide compression. For that matter most shared hosting companies have that disabled and you have to compress using PHP zlib calls.

So there are many reasons for doing it this way.

BTW, you can use http://web-sniffer.net/ to check just about any URL to see if they are using compression. It's the one I use to check data size being sent.

And the bandwidth used by the main site isn't much. A little over 1 gig a month or around 40-50 meg a day. It even went DOWN a little on average since we opened the new site layout. We get close to 300,000 page hits a month. Not that much but decent.

Now the Main Game is different. The game uses about 12 gig of bandwidth a month. There were a couple of months where it was close to 21 gig. With 3 million to 6 million page hits a month. Tends to be really high for the first couple of months after a reset and then stop to a steady 3-4 million a month after that.



_________________
PJ's Annoyingly Useless Blog
ADOdb Lite
Template Lite
Offline
 Profile  
 
 Post subject: Re: Javascript code
PostPosted: Sat Oct 18, 2008 1:19 pm 
Newbie
Newbie

Joined: Mon Sep 01, 2008 10:22 pm
Posts: 30
Panama Jack wrote:
Yes, we could enable site wide compression but there are problems with that as well. We have more than one site on the server and not all of the software is written by us. You would be surprised by how many software packages don't check for site wide zlib compression. They just check to see if the zlib library is available and start compressing. This causes some output to be compressed twice. Once by the software package and then again by the site wide compression. The user then gets garbage.


You could configure apache to use virtual hosts, and then set compression on a per-directory basis if need be. However, point taken; you would rapidly be approaching the point where configuration and management of the server would be a real hassle.

Panama Jack wrote:
Now the Main Game is different. The game uses about 12 gig of bandwidth a month. There were a couple of months where it was close to 21 gig. With 3 million to 6 million page hits a month. Tends to be really high for the first couple of months after a reset and then stop to a steady 3-4 million a month after that.


Even 12 gig is not that big a deal, what with places giving away free web sites with 100 GB of transfer/month. The bigger issue is CPU and/or database usage. Many free/low-cost hosting sites give you a bandwidth cap that you can't realistically reach with anything other than static HTML, because you'll exceed your CPU/memory usage limits first (limits which often aren't explicitly stated in the agreement, either).


Offline
 Profile  
 
 Post subject: Re: Javascript code
PostPosted: Sun Oct 19, 2008 2:59 am 
Developer
Developer
User avatar

Joined: Wed Feb 19, 2003 6:07 pm
Posts: 2930
gizmo wrote:
The bigger issue is CPU and/or database usage. Many free/low-cost hosting sites give you a bandwidth cap that you can't realistically reach with anything other than static HTML, because you'll exceed your CPU/memory usage limits first (limits which often aren't explicitly stated in the agreement, either).


Very true...

One of the things we battle with is trying to make the game use less CPU. Unfortunately the database is the biggest CPU hog because so much data is being worked with. The more features we add the more hits to the database. We would use database caching if we could but the game is so dynamic it wouldn't be used most of the time.



_________________
PJ's Annoyingly Useless Blog
ADOdb Lite
Template Lite
Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 1 of 1 [ 6 posts ] 


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

cron