I recently started using svg images in my sites. Some of them are complex and quite big, so I've started compressing them. They compress really well.
Why would one ever not use SVGZs (instead of the uncompressed version)? Are there well-known pitfalls that I should be aware of?
As long as your webserver sets the proper Content-Encoding HTTP header it should work in all browsers that support SVG.
The one pitfall I know of is if you want to be able to open the svgz files from disk locally (that is: without using a webserver). That doesn't work in all browsers.
Also if your svg files are big, then you should consider preprocessing them with SVG Scour or similar. It's rather common to see vector graphics editors such as Illustrator and Inkscape output display-redundant data in the files (binary blobs or custom xml markup).
Is it for desktop browsers, mobile? I know Opera supports SVGZ natively since 8.0 at least (maybe even earlier).
What server? Apache, IIS? You might have to configure it and/or mess with .htaccess. Here's a howto for Apache: http://kaioa.com/node/45
Keep in mind that the server might be already serving your content compressed, if your client supports it, as SVGZ is just a normal SVG with gzip compression applied.
Related
<img src="./img/pic.png">
<img src="./img/pic.svg">
Locally the two lines above work and display two pictures but once deployed remotely (for example, on a ftp) only the png displays (permissions are set to the most permissive for both files).
Any idea?
By the way, it seems any sort on svg cannot be display, I can access to pic using its path but loading in html does not work.
I'm sure this is real stupid.
Seems weird as SVG support is pretty good on a lot of browsers
http://caniuse.com/#search=svg
This could be down to your server, If it's an Apache server you could try adding
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
to the .htaccess.
Progressive JPEGs seem pretty useful for performance purposes. I've found: https://github.com/gruntjs/grunt-contrib-imagemin, which has an option to progressive'ify your jpegs. It is using http://libjpeg-turbo.virtualgl.org/ under the hood. This is great; however, it seems like my images load top down still.
Questions:
Do pjpegs have their own file extension?
Do pjpegs have their own mime types?
What is a good way to test that the pjpeg is doing what it needs to do?
Every JPEG library I have seen recently decodes progressive JPEG image. A progressive JPEG breaks each component into two or more scan (as opposed to 1 scan per component in sequential JPEG).
In theory, an application can redisplay a progressive JPEG image after each scan. In a web browser, that effect would give you images that start out as 8x8 blocks the get clearer.
In ye olde days of internet over 1200 baud serial lines that made a lot of sense.
Now, most images can be downloaded so fast that there is little need for a web browser to progressively display an image, even when it is in progressive JPEG.
To use progressive JPEGs, you just need an encoder that creates them
Progressive JPEGs generally do have their own extension.
No
Just display the image. If it is visible in your web browser, it is doing what it needs to do.
I am building an offline Html5 App and I have to prepare my manifest file for caching all files I am using.In previous releases of JQM I just included:
jquery.mobile-x.x.x.min.js, jquery.mobile-x.x.s.min.css, the 2 icon files and the spinner.gif....And my App worked just fine...
Now it turns out that JQM 1.4.1 includes a bunch of files that I don't know if I have to cache them all?
What should I do with all these files?
Do I have to include them all in my manifest file?
This is not a thorough answer but no, you don't need both the regular and "minified" version of all those files. The .min.* files should theoretically load a bit faster and are worth bundling into the cache manifest. Also if you are targeting multiple device formats, you might want both the PNG and SVG images. However if you are targeting a single device profile (as we are) you can probably isolate only the image format that you want. The default is now SVG with PNGs as backup for browsers that don't support vector images fully.
Anyone have suggestions on how to best handle using App Cache when you have sets of assets used in one browser but not in another?
Example: OGG audio for Firefox and MP3 for IE. I can cache both types of files, but audio is huge and would store twice as many files as the browser can use.
My best thought is to create several different manifests. For example, one to load assets common to all browsers, and then a separate manifest for, say, MP3's, and load a page in an iframe that calls this manifest once I can determine on the client side that they're using IE. If however I find that they're using Firefox, I can load another page (with the attached OGG manifest) in the iframe.
Would this work or is there a more elegant solution?
For now I'm just using a nginx rewrite rule like this
location / {
if ($http_user_agent ~ Firefox) {
rewrite ^.*\/(app.manifest)$ $scheme://$http_host/moz.manifest redirect;
}
}
Most web servers will let you define similar rewrite rules. This is a good option because it's fast and doesn't require any further installation of software.
This guy is checking which browser using PHP, but you could do this using any framework, preferably something fast like Node or plain ruby Rack.
On my website, I intend to stream background audio using the HTML5 <audio> tag. However, even after cutting down on the track length, my two files (MP3 and OGG Vorbis, for different browsers) end up at just short of 5MB a piece.
Due to this, it would be nice to ensure loading time and bandwidth is conserved by caching the files. What I would like to know, but can't seem to find, is if it's possible to force the files to cache, or if browsers would normally cache the files at all.
Thanks for your input!
You can not force caching. Browser treats these files as standard resources, so make sure that your server is properly configured to make caching as likely as possible. (Returns valid ETag, Expires and Cache-Control, no Pragma:none, 304 Not modified responses, etc..). HTML5 local storage can be used (but not worth the effort) to cache small items like pictures.
Mobile browsers have such a small cache, that even this doesn't help and they will flush the cache pretty soon.
Fast forward 7 years, and you can now easily do this with a Service Worker. You could even get crafty and cache/combine various Range requests if you wanted.
https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker