When using CSS3 and custom fonts, the client needs to download .oft or .ttf files. These files can be >50K. Can these files be compressed? How? Assuming Apache web server.
I am looking for a compression technique or an Apache configuration. Any ideas will help because downloading +50K files should be prevented.
.ttf files compress quite well (analysis with hex editor shows a lot of 0x00's and simple zipping reduces their size to 50% or even less of original size - at least fonts I checked), so I think any compression script would do the trick and I think same rule applies oft files as well.
Related
In my cpanel, threre is 30GB Project file, i am trying to compress it and downloading
but unfortunatly, file compression is taken too much time.
can you suggest any efficient way to compress it and can download easily
My images coming from Contentful doesn't seems to be gzip compressed. Is there any setting that I need to make?
This link talks about that this is possible but I couldn't find any such setting. Can you please let me know how can I ensure that images I'm getting from Contentful cloudfront are gzip encoded?
there is no need for GZIP compression on images. GZIP and other compression algorithms only make sense for text-based formats. Images (and other binary formats) rely on different compression algorithms.
You can find more information here: https://webmasters.stackexchange.com/questions/8382/is-gzipping-images-worth-it-for-a-small-size-reduction-but-overhead-compressing
Hope that helps. :)
I have a website where I was forced to move over a bunch of pdf files from a windows server and many of the files have capitalization. This of course shows a file not found if someone has a link going to the file without the correct case. Its a big problem since my client has a many links pointing to these files with a myriad of case options.
I have enabled the speling module in apache and it seems to have helped with ignoring case for urls but NOT FOR THE PDFs.
Does anyone have a work around for this?
I followed these instructions for enabling the speling module: http://keystoneit.wordpress.com/2007/02/19/making-apache-case-insensitive/
As it's a file system feature under *nix boxes rather than apache specifically, you can batch rename all your pdf files to small case using shell or using some server-side scripting language and can
redirect all non-matching pdf requests to a guidelines page using htaccess where you can inform the user to type small case letters for the pdf file and also
you can give him download link with lowercase letters for the filename extracted from the url..
I read some articles about HTTP headers compression. Today I installed YSlow and it recommends that I compress the resources (text/html, javascript, css and images). Now I'm reading the documentation for Apache mod_deflate but in the example don't compress images.
Should I or should I not compress images in my site?
Your images should already be compressed - any extra compression won't have any noticeable effect on filesize, but will increase processing time.
.png files use DEFLATE compression already.
.jpg files generally use lossy compression.
.gif files use LZW compression.
Compressing files that have already been compressed very rarely results in a reduction in filesize, and can often increase filesize.
Images such as GIF, JPEG or PNG are already compressed via highly specialized algorithms that achieve better result than general purpose algorithms such as deflate.
Therefore, re-compressing them yields little to no gain in size, and can even make files bigger, with the added cost of server-side processing.
So, in other words... do not compress images.
SVGs should be compressed by Apache mod_deflate as
AddType image/svg+xml svg
AddOutputFilterByType DEFLATE image/svg+xml
More information at https://httpd.apache.org/docs/2.4/mod/mod_deflate.html.
I'm developing a website, I'm using gzip.exe to pre-compress css and js files (it's only 1 css file that went from 4.53 KB to 1.50 KB, and a js file containing the jquery and some scripts that went from 72.8 KB to 24.7 KB)
these files are style.gz and js.gz and served as static files.
The problem is that they don't work with Safari (v5.0.2) not the css neither the js.
the work fine for these browsers:
Firefox 3.6.10 / Google Chrome 6.0.4... / IE 8 x64 / Flock 3.0.6 / Maxthon 2.5.15... / Avant Browser 2010
All of them work fine except Safari
I'm using Windows 7 x64
You should get the server to gzip them - this can be done in the htaccess file and works just fine.
+1 What rob said.
What you're doing is a hack that is not supposed to work, so you can't really complain when it fails. Serving a gzip resource is completely different to serving a resource with a different type using a Content-Encoding header to compress it on the wire.
Serving pre-gzipped files will obviously also fail for user agents that don't understand gzip. The HTTP standard provides a mechanism for negotiating this: Accept-Encoding and Content-Encoding. Unless you re-implement that mechanism in a complete, standard-compliant way (and the article in Michael's link doesn't begin to get that right), you're blocking clients.
This is all unnecessary. Gzip is fast and servers typically cache the compressed version of static content so you gain nothing by trying to second-guess it. HTTP compression is part of the web server's core competency, let the web server do its job and leave gzip alone.
There is a way around this issue. Basically, you need to use .jgz instead of .gz as the extension for JavaScript files:
Fix for .gz and Safari