Cart
[Home] [By Thread] [By Date] [Recent Entries]
(Sorry for the off-topic. But as it may be helpful to others, I'll
keep this on the list)
Well... Let's go for your case... This is information published by your web browser every time one requests a web page from www.ballsome.com: Server: Apache/1.3.26 (Unix) FrontPage/5.0.0.0 mod_ssl/2.8.10 OpenSSL/0.9.6a For the Apache server, I found the following HOWTO (from our company's docs): 1. Enable MultiViews on your apache configuration. 2. Add the MIME types for the extensions you need (xml and xsl, both text/xml IIRC) 3. For each file you need compressed, do: cp file.xml file.xml.xml gzip -9 file.xml 4. You'll end up with double files (file.xml.xml and file.xml.gz). IMPORTANT: The original file, named "file.xml" should disappear from sight... 5. You're ready. Let's test it. 6. Launch a net sniffer, like ethereal, either on your client or your server. 5. Point your browser to the address of the former file.xml. If everything is OK... a) Your browser should show the page to you. b) Your net sniffer should NOT show the XML in the HTTP response, but the compressed version. If you look at the headers, there should be a "Accept-Encoding: gzip" header on the request packet. And there should be a header on the response indicating that it is serving file.xml.gz instead. If the "Accept-Encoding: gzip" header is not present on the request, that means that your browser does not support compressed content. However, the file.xml.xml should be served instead, so the content will still be viewed. If file.xml still existed, no content negotiation would occur, and so the original uncompressed file would be served. NO CHANGES ARE REQUIRED IN YOUR PAGES. Thought 4: (Continues the saga) If you have a relevant part of common templates, and you want to keep the impact on the user who comes for the first time low, while also avoiding impact on the user that wants to access the homepage, you may take the common part away, and use <xsl:import/> or <xsl:include/> to include it in your stylesheet. That way, a user who comes in for the first time on an article should load: article.xml article.xsl common.xsl A user who comes in for the first time on the homepage: home.xml home.xsl common.xsl And a user who switches from article to home: home.xml home.xsl (not the common part) And vice-versa: article.xml article.xsl (not the common part) However, this may be counter-effective, as there is one more file to load the first time, and one more file to load when you switch. Real measuring of times should be done to decide on onw or the other possibilities: Rule of thumb: If the common part is big enough, taking it apart would be good. If the individual parts are small enough, integrating them (and the common part) in a single file would be better. Now, the question "how big is big?" and "how small is small?" are impossible to answer without knowing: - The "distance" between your server's location and your visitors location. - Your visitors technology (56K, ISDN, xDSL, broader). - Your server's bandwidth. These factors, (and maybe also humidity ;-) will determine whether a file is big or not and whether a file is small or not. Good luck! Antonio Fiol Bonnín Joel Konkle-Parker wrote: Yeah, those are two good points, but here's my thoughts on the subject. First, being a review site, alot of our users enter the site through the article pages. Now I know it's not asking much to download another few k worth of homepage stylesheet, but everything counts, right? Of course, compression could solve that problem... Unfortunately I don't know anything about it. A few tips please? XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
