Gzip is a method of compressing files (making them smaller) for faster network transfers.
It is also a file format.Compression allows your web server to provide smaller file sizes which load faster for your website users.
Enabling gzip compression is a standard practice. If you are not using it for some reason, your webpages are likely slower than your competitors.
How to enable Gzip compression
Compression is enabled via webserver configuration
Different web servers have different instructions (explained below)
Here are the most common ways to enable compression including .htaccess, Apache, Nginx, and Litespeed webservers.
Enable compression via .htaccess
For most people reading this, compression is enabled by adding some code to a file called .htaccess on their web host/server. This means going to the file manager (or wherever you go to add or upload files) on your webhost.
The .htaccess file controls many important things for your site. If you are not familiar with the .htaccess file, please read my working with .htaccess article to get some know how before changing it.
The code below should be added to your .htaccess file...
The instructions and code above will work on Apache. If they are not working there is another way that may work for you. If the above code did not seem to work, remove it from your .htaccess file and try this one instead...
# Disable for IE < 6 because there are some known problems gzip_disable "MSIE [1-6].(?!.*SV1)";
# Add a vary header for downstream proxies to avoid sending cached gzipped files to IE6 gzip_vary on;
Enable compression on Litespeed webservers
The ideal way to enable compression in Litespeed is to do it through the configuration under "tuning". Just go down to "enable compression" and check to see if it is on, if not click "edit" then choose to turn it on. While you are there, look over the several Gzip options that are nearby.
How effective is gzip compression?
Compression of your HTML and CSS files with gzip typically saves around fifty to seventy percent of the file size. This means that it takes less time to load your pages, and less bandwidth is used over all.
How compressed files work on the web
When a request is made by a browser for a page from your site your webserver returns the smaller compressed file if the browser indicates that it understands the compression. All modern browsers understand and accept compressed files.
I see you already did that for the .mem and .data mime types, but perhaps you should add all the unique file extensions that a unity webgl will serve?
I'm kind of confused why you are doing rewrites? If the unity webgl build creates static files, you shouldn't have to use any rewrites?
What are you running on IIS, is it ASP. NET web forms, MVC, if so what version of ASP MVC, etc.
Or post a URL and I can take a look. That's just off the top of my head; I haven't used WebGL export yet so I'm not familiar with the different files it exports.
I do the rewrites as that is the unity way of doing things. as outlined in the top post in the section starting
"and the .htaccess file (which is not IIS friendly directly but can be imported) says:"
Thanks very much for answering though!!! I really appreciate any input.
RE THE SERVER: Vanilla 2008 Datacenter edition. so.. .Net web forms I guess. I have full access to the servers configs.
np, in a nutshell I think you just add mime types and configure compression in webconfig. I don't think any rewrites should be necessary. I'm not familiar with the htaccess importer, I'd probably just configure it manually and skip the htaccess.
Yup, read that one. Tried it. Compression is on and working fine.
Here is a quick precis
this is what I did:
1) Upload to server (I was not clear if I had to actually upload the two huge .mem and .data file in /DATA, from my reading of the rewrite rules below, "No, I do not have to" since all requests for those files will be redirected to their pre-compressed cousins. (but I did anyways to be sure)
2) checked that the web.config was being honoured to serve out the .mem and .data stuff (I also actually tried hard-coding the MIME TYPES just for sanities sake, yup, web.config or hard coded is same) EDIT <--- ACTUALLY In the end I had to hard code them.
3) Imported the rules into URL rewrite via the IMPORT RULES button and double checked they were sensible. They all seemed fine - 4 rules - redirecting unzipped requests to zipped equivalents. (they need little fix though as outlined in top post)
4) Checked that the server has dynamic and static compression installed and enabled for the domain (which it does)
5) revisited the .htaccess to see what I had missed.
It's the final bit where in the .htaccess it would have been handled by:
it looks like something must be messed up in the web.config. all static files are throwing 500's. you may want to turn on customErrors so you can see the IIS error.
<customErrors mode="RemoteOnly"/>
"RemoteOnly" will allow you to remote into the server and check the response, if it's a staging environment where you don't care, you can set it to "On"
Yup. Many thanks - I have fixed particular error now. It was a stray character in the xml. Doh
However the real issue appears to be:
HTTP Error 404.3 - Not Found The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
which I clearly have done.
I will go hard code them in the IIS config instead and rip the web.config again. sigh.
The STATIC section of the web.config was not being honored. Putting the MIME types into IIS finally allowed the files throughBUT now they appear to not be being unencoded at my side.
Sigh.
application/x-javascript was the type I put on the .jsgz files.... is that wrong?
I just did a test WebGL build in ASP MVC 4 website:
Due to the directory structure of MVC I changed some relative paths for "Data/" to "/Data/" in the index.html file that the webgl build spits out.
As expected 403.4 errors on the MIME types that I have not configured in my web.config yet,
Added the MIME maps to the web config: <staticContent> <mimeMap fileExtension=".data" mimeType="application/octet-stream" /> <mimeMap fileExtension=".mem" mimeType="application/octet-stream" /> </staticContent>
For compression.. I'll try deploying to my shared web host, as I don't want to change IIS express configuration right now. I'm just using standard web.config compression, relevant web.config is as follows:
I pretty much picked that up off some website somewhere. I think this part should enable compression on everything.. <add mimeType="*/*" enabled="true"/>
and it appears to be gzipping and serving all the files,
I'm not using any rewrites, I think that was specific to wahtever configuration the unity people were using. Although, I think my configuration is not using the files from the "compressed" directory. Those must be pre-gzipped or something. I've never done that, I've always had my web server do the gzipping and have the server cache the response. I'll have to see about that next..
The rewrites are to enable the huge versions of the files to be replaced "pre-realtime" with the pre-zipped versions of the files. Since zipping 124mb everytime someone wanted to play your game would soon kill your server.
(they should be in the compressed folder)
Well, it sounds like I am right at the very verge of getting this thing working.
Although I am back at exactly the same point I was when I started this thread.
.jsgz files being served. Nothing else happening once they are returned. I must have them encoded wrong or something stupid. will keep digging then. thanks for your tips.
RE POST: Aye I remember that post from years ago, probably when I first did gzip stuff in my own apps. I have actually written custom http handlers in the past, - that used gzip - unbelievably, looking at the total lack of understanding going on today.
Vanilla 2008 server. IIS 7.5, whatever came on that.
Model View Controller? Errrr.... Honestly I don't know. Pretty sure that post dates the servers birthdate.
I only use this box to shove out files and the occasional, very lightweight, Asp .Net programming job. It's just a file workhorse. Hence me being pretty unsure about its potential guts.
EDIT: Hmm I seem to recall that stuff came out about a year after the server did. so I doubt it.
I think the rewrites are not adding the correct HTTP header to the response, that should tell the browser it's using compression. It should be something like "content-encoding: gzip" or whatever.
It seems like the browser doesn't realize that the response is gzipped, and it's getting all this crazy garbled gzipped javascript data that it can't understand. Therefore the "unexpected token" errors
there's no content-encoding header in the response, so the browser just tries to read it without decompressing and it looks like this:
it still doesn't seem to be passing Content-Encoding header back to chrome at least. It's weird that it's working in firefox.. When you look at the response, does it look like javascript?
without those it does not send those gzip headers, period. so either that is somehow affecting the wrong output and I need to put it somewhere else.... Like in the main IIS config? I have zero idea how to do that though.
Well since those files are precompressed, maybe you should disable httpCompression on them in web config. It's possible they are getting double compressed.
In which case the browser would decompress and itd still look like garbage.
Hm, just to make sure I'd try deleting web config, hit the site and make sure you get an error, then push web config again.. Or just restart site in IIS or something. I've had a few times where it was hanging onto certain web config settings.
Probably not the problem, but just to make sure.
I'll have to take a look again in a few mins when I'm back at a computer, that is a mystery for sure...
did that. removed web.config, 404.3, added custom web.config with the gzip header handling included. 404.3 (that IS a mystery, checked it wasn't xml order related etc.),
so reverted back to hard coded IIS management MIME types, that gets us past the 404.3 and onto the files being served but the response encoding being utterly ignored.
Tried mangling the return content types, just broke stuff as expected, with pretty warnings.
Did everything I could think of. went through all the configurations again. rebooted domain.
In precis: Attempting to indicate .jsgz MIME type in the web.config after the URL rewrite fails on a 404.3 (as you saw), that is puzzling.
Placing .jsgz in the default mime types and using the rewrite thing for the content headers looks like it works on paper but nothing happens on the client side for the unzipping.
Totally befuddled.
There HAS TO BE SOMEONE who has done this. Jeepers, it's so basic.
Well. I have even ripped the web.config completely now.
and weirdly the server IS NOW appending the gzip to the response even without massage.
an it STILL doesn't blumming work. So basically I have put on the files, added the MIME types to the main domain information, checked the responses are valid with the right headers.
The unity gzipped files looked like they were super-compressed; maybe it's running into errors because of the high compression or something. Or maybe unity's spitting out invalid compressed files. Who knows, it's a beta.
Is this for a production game where you need super optimized compression? Can always skip the precompressed files, disable the rewrites, re-enable the httpCompression and use IIS built in gzipping, make sure it's using static compression so it can be cached in the browser. Admittedly it wasn't as compressed as those precompressed files, maybe like 25mb instead of 15mb or whatever. On the fly compression may kind of tax the web server, I'm not sure if/how IIS caches those gzipped responses. I would hope if the web server is gzipping a static file, it caches it somewhere. I'm not sure.
Precompressed would obviously be the best, but it's a beta (who knows), and it's friday, I kinda give up for now xD
If you continue down the precompressed route, I'd try skipping unity's precompressed files and compressing them on your own. Just to rule that out. Or verify w/ someone that those precompressed files are working.
Yeah me too. Thanks dude. I too read that post about the super compression, In fact I think I've read like every relevant post on the first 30 pages of goggle results for several search terms.
Fact is without the compression the files are ENORMOUS. VAST. that one project has just a CUBE and a PLANE in it.
it comes in a nearly a quarter of a gig mate. hardly serviceable.
I've raised a request with my hosts, maybe they will take pity on me.
EDIT: They did not.
and I have tried every type of build. lowest to highest. and its not compression its optimisation they do. I watched the hour long video about it earlier.
Hi, I'm using IIS server. I built a test game to see if I can help, it's just a cube and works ( worked using both optimization 'slow' and 'fastest', fastest is used now ): http://www.liberalistudios.com/trabalhos/webgl/example/
I thought you were using MVC or friendly url but your site seems to be using just html. ( http://kaycare.co.uk/index.html ) What I would suggest to you is: - If you're not using ASP NET to backup and replace your web.config with the one above. - Test a build using just a cube - If using just a cube and web.config works but your game doesn't I think it is the compression problem that you're saying!
Fact is without the compression the files are ENORMOUS. VAST. that one project has just a CUBE and a PLANE in it.
Right - I mean as a temporary workaround for the issue with the precompressed files, you could skip using them and have IIS gzip the raw ones. The total size of downloading this empty build with IIS gzipping it was 31.9MB. IIS was still able to gzip it pretty well. Not as good as pre-compressed, but still fairly compressed.
(in chrome "size" is the size downloaded, "content" is the actual uncompressed size of the file - so IIS gzip compressed build.js from 108mb down to 26.5mb)
I did the webgl build on my computer at work, so I forget how big the precompressed files were, I think they were only slightly smaller.
My hosts were ultimately unhelpful. so I kept digging.
I managed to find this in the new firefox developer toolbar. "The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature."
So I am looking into that next, tried disabling Dynamic and Static compression manually via IIS on the site too, so it's not that. :\ another day, another segfault
plus, DISABLING dynamic compression (manually, not in the config)
and manually adding the (entire list of 5) types to the MIME register
and adding application/x-javascript; charset=UTF-8 to the MIME information of jsgz.
appears to have done the job!!!!!! WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOTage.!!!!!! Still checking but heck I can see real script content where there was only compressed noise before. That has to work... testing now.
EDIT: Yup files being served. I'll see if I can get it to work without the hardcoding....
Nice, glad you got that figured out! What an ordeal...
Next week I think I'm gonna attack it from a different angle. I like to try and configure things in web.config and code as opposed to IIS stuff.. I'm gonna try to route the requests for the unity JS / MEM / DATA files to an MVC action... which would contain code that does the same thing that those URL rewrites are doing (check if the request headers indicate the browser supports compression, and serve out the correct precompressed file).
I believe you can route requests for specific directory/file paths to ASP MVC actions instead of having IIS serve them out as static files, by configuring system.webServer handlers in the web.config, and then set up some MVC routes that catch the requests for those files.
(I think it's also probably possible to do with a regular ASP .NET webforms project, but I'm not a big fan.. gotta have my MVC)
My goal is basically to get it set up so you can just drop the unity WebGL build into the root of the website and have it work, without having to change stuff in IIS.
Once again tho, nice work! I'm sure people trying to host on a windows server will find this helpful.
Just tried the alternate solution I mentioned in the above post, and it seems to work. I haven't thought through all the possible implications of doing this instead of the IIS rewrite.
Workflow is basically: do your WebGL build, then copy it into the root of this ASP MVC website. As long as IIS is configured correctly to host the website (integrated pipeline, .NET 4.5), it should work without any IIS configuration changes or rewrite rules.
Some details of the implementation:
1. Disable IIS serving out the static JS, MEM, and DATA files, but only for the /Data/ directory. Add system.webServer handlers to web.config:
Code (CSharp):
<system.webServer>
...
<handlers>
<!-- create handlers so requests to the Unity WebGL static files get routed through ASP MVC -->
With those handlers in place, IIS won't serve out the static files in the Data/ directory.
2. Next, configure MVC routing in RouteConfig.cs. Catch the requests for static files in the Data directory, and send them to the UnityStaticFile controller's Index action, with the requested file name as a parameter.
Code is kind of hacked together, but it basically does the same thing that those IIS rewrites are doing - if there is no "accept-encoding" header, it just serves the non-gzipped files. If there is an "accept-encoding: gzip" header, it sets the "Response Content-Encoding: gzip" header, and returns the compressed file. I'm using an [OutputCache] attribute to enable caching, with the VaryByHeader set to Accept-Encoding, so it should serve a cached response correctly depending on the Accept-Encoding header. (disclaimer: I have not fully tested, but the code path returning the compressed files worked for me in chrome)
4. I set up the Home controller's Index action (it handles requests to the website root) to just serve the index.html file. So it's not using an ASP MVC view. This just basically serves the index.html file (in an ASP MVC way..) when you hit the root of the website.
5. Side note, if running localhost in Visual Studio you may need to disable Browser Link, or it'll throw Out of Memory exceptions on huge static javascript files:
댓글 영역