I want to reduce page load, since comparing webp vs jpg or png, webp has much lower size(in KB), but here is problem it does not work in Edge,IE(11) and older Safari(5.1.7).
Looking for solution I found post by #WaughWaugh https://stackoverflow.com/a/56021203/10966377 which posted tool which converts webp to png using base64, but before I could sleep without stress, doesnt that just increase unwanted page load because it has to convert webp to png?
It doesn't transfer PNGs across the wire.
The costs come from downloading the library itself and the CPU/memory usage of running it.
You can use a combination of Content Negotiation and URL rewriting to let the webserver handle it, but that won't enable WebP for non-supporting browsers, of course. Here's how you can do it with Apache (from .htaccess in image folder):
<If "%{HTTP_ACCEPT} =~ /webp/">
Options +MultiViews
</If>
<Else>
RewriteEngine on
RewriteCond "$1.jpg" -f
RewriteRule "^(.*)$" "$1.jpg"
</Else>
So if the browser request contains "webp" in the Accept header, it uses ConNeg, otherwise the JPG is served, if it exists.
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.
I'm displaying SVG images with two methods on a website, css background and <img> tag, neither of which are working. However, I'm able to load svg files via the <object> method, but this doesn't work for this case (it could replace <img> but not background images). Because someone will ask, the SVG files are there, and they are accessible if you go to their url directly.
I've been testing and working with this site on a separate, private server and the SVG images were displaying properly there. This leads me to believe that the issue is a result of something server-side.
I've tried adding the following to the .htaccess file, but it didn't fix anything:
AddType image/svg xml svg svgz
AddEncoding gzip svgz
I'm aware of some alternative methods that involve httpd.conf, but I don't have access to this.
Here's the troublesome site: http://www.focusvitamins.com/get-started/
Here's the working test site: http://focus.steadfa.st/dtclanding2015/
Thanks for the help!
That should be
AddType image/svg+xml svg svgz
as the mime-type for svg images is image/svg+xml. You are missing a +
I am having the problem that Firefox is not sending the Referer in the HTTP headers when I'm accessing an MP3 file through HTML5.
I'm using the player from jPlayer.org to play mp3 files, and I'm trying to prevent people from downloading the songs by reading the URL from a HTTP-sniffer/FireBug/similar. My approach to this is to check the HTTP headers in my .htaccess file:
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule ^play/(\S+)$ /uploads/error.mp3
RewriteRule ^play/(\S+)$ /uploads/mp3/$1.mp3
These three lines tells the browser to play error.mp3 if the HTTP-referer is not set to something with mydomain.com. Otherwise, it gets the real mp3 file.
This works fine in Chrome, Internet Explorer 7/8/9, Safari(PC) and Opera. However, in Firefox (both PC and Mac) and Safari (Mac), it doesn't work. It seems this is because the HTTP referer is not sent at all. When I look in FireBug, I can't see the Referer any place in the Request-headers, so I guess it's not sent at all? I can see it in Chrome when I look in the Network tab in the web developer tools.
Is anyone else familiar with this problem? Do you have any idea how I can prevent download of the MP3 files or at least make it harder to download? Passing the MP3 files through PHP doesn't seem to work, as pause/resume won't work.
I don't believe Firefox supports the MP3 format within HTML5 audio. Maybe you should try this code with ogg files as well?
See Media formats supported by the HTML audio and video elements.
Like tim said, Firefox does not support MP3 in HTML5 http://caniuse.com/#search=audio in which case you should have a fallback to oog or wav.
Of course you said you are using the player from jplayer.org, which has flash fallbacks and in that case we are not really dealing with html5 anymore.
Supported html5 formats from jPlayer
http://www.jplayer.org/latest/developer-guide/#reference-html5-audio-format
HTML5 Audio Format
Firefox (OSX, Win): WEBMA, OGA
Safari (OSX, Win): MP3, M4A
Mobile Safari iOS4 (iPad, iPhone, iPod): MP3, M4A
Opera (OSX, Win): WEBMA, OGA
Chrome (OSX, Win): WEBMA, OGA, MP3, M4A
IE9 (Win): MP3, M4A (Can install the WebM codec.)
So most likely your header stuff is related to FF not supporting mp3 anyways.
It could also be something wierd like missing mime type on server. Then again if we are logical, any request a browser makes should be accompanied by a referrer url whether it's requesting a file it supports or not ..hmm.
One thing you could try is instead of linking the mp3 directly is give it an id, and make a request to your server for that, then via a redirect return an mp3.
And for sanity sake ..test it with an oog/wav, and also remove your referrer detection ..just to make sure it works at all :)
That said, if you are really concerned with leeches, i wouldn't put too much weight on referrer information, as that's pretty simple to spoof both in FF & Chrome. With a handcrafted http-client (just a few lines of code in most languages) you can spoof just about anything under the sun: cookies, referrer, cross-domain policies, and whatnot ..anyways getting off topic :)
But yes, referrer information will protect you from 95% of the population out there.
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
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.