I've heard a lot about the importance of using sprites in order to get your request count down. But my thinking is that rather than use sprites, you can use URIs to accomplish the same thing, and much easier (no sprite creation needed).
Is it better to use sprites or uris?
Base64-encoded data is about 1/3 larger than raw bytes, so on pages where downloading all the image data takes more than three times as long as making a request, CSS sprites are superior from a performance basis.
Also, inline data URIs make the file itself take as long to load as the actual data plus the base64-encoded images. If the data URIs are on your actual HTML page, that means rendering stops and waits for the image to load. If the data URIs are in your stylesheet, that means any rules after the data URI have to wait for it before they can be processed. On the other hand, with a sprite file, the images can load concurrently with your other resources. That may be worth the cost of one extra request, especially when you factor in the base64 penalty.
I suppose that support for IE5, 6 and 7 would be a good reason to use sprites over URIs, if those targets are important to you.
Related
If I visit a website with the facebook conversion pixel installed (such as https://www.walmart.com/), I notice that several different JavaScript files are loaded by the pixel.
The first one is https://connect.facebook.net/en_US/fbevents.js.
The second one is
https://connect.facebook.net/signals/config/168539446845503?v=2.9.2&r=stable. This one seems to have some user specific configuration data baked into the file.
The third one is https://connect.facebook.net/signals/plugins/inferredEvents.js?v=2.9.2
What I don't understand is, why doesn't Facebook simply consolidate all of these into one request, like https://connect.facebook.net/en_US/168539446845503/fbevents.js?v=2.9.2&r=stable, and then simply return one file with everything in it? This would be able to do everything the conversion pixel does now, but with 1 request instead of 3.
As the page makes more than a hundred requests for its loading, loading 1 javascript file instead of 3 would not be a significant improvement.
Facebook chose to divide in 3 files for a better design, probably :
1 generic library : fbevents.js
1 more specific : inferredEvents.js, that uses the first one
1 file that contains generated code, probably specific to the merchant 168539446845503 (Walmart?)
This fragmentation makes code maintenance easier (test, reusability, bug fix).
And finally, the generic files fbevents.js and inferredEvents.js can be cached by the browser and reused on other web sites. This is a kind of optimization, possibly better than the one you suggest.
Having multiple resource requests to the same origin is FAR FAR less of an issue than it was a few years ago:
Internet speeds and are much faster.
Latency is less (most notably so on 5G phones).
HTTP/3 protocol has many improvements which help when multiplexing files simultaneously from the same server.
Browsers don't limit active number of connections to a site as agressively they used to (that doesn't matter with HTTP/3 anyway).
Facebook uses HTTP/3 as you can see here:
I am trying to optimize my page by replacing image urls with DATA-URI but the images are not rendering after converting to DATA URI.
Here is my code to converting normal urls to data uri:
$imgurl= "https://www.cashy.in/images/banners/0ad08aafdd0887ed79f9fcc4321d54ed.png";
$type=substr($imgurl, -3);
$newimg=base64_encode($imgurl);
$o_img="data:image/".$type.";base64,".$newimg;
As discussed above, you don't encode the URL of the image itself, you have to encode the actual data.
As such, you should use something like the following code:
$imgurl= "https://www.cashy.in/images/banners/0ad08aafdd0887ed79f9fcc4321d54ed.png";
$type=substr($imgurl, -3);
$newimg=base64_encode(file_get_contents($imgurl));
$o_img="data:image/".$type.";base64,".$newimg;
However, when doing this you need to understand that you are increasing the size of your generated HTML by the size of the image (plus the 33% overhead inherent in base64 encoding). Only do this when the image itself is very small and the overheads of an extra HTTP request outweigh the extra download required.
I am trying to cache rendered animations to the apple watch (these are generated at run time). I have saved the frames of each animation as JPEG #1x with compression of 0.1. The sum of all the frames is less then 1.2 MB. I clear the cache before I start caching. However only about half the animations are cached. The documentation says that the cache is 5MB. What am I doing wrong?
If you want to send image data to the Watch programmatically (i.e. not at compile time), WKInterfaceDevice provides two methods:
addCachedImage:name: accepts a UIImage, encodes it as PNG image data, and transmits it to the cache. So, if you create a UIImage from JPEG data, you are actually decoding the JPEG data into an image, then re-encoding it as PNG before it's sent to the cache (thereby negating the effects of JPEG-encoding in the first place).
addCachedImageWithData:name: accepts NSData and transmits the unaltered data directly to the cache. So, if you encode your image to NSData using UIImageJpegRepresentation and pass it to this method, you'll transmit and store less in the cache. I use this technique for all of my images, unless I need the benefits of a PNG image; in that case, I actually encode my own NSData using UIImagePngRepresentation and send it using this method.
For debugging purposes, it's helpful to use the [[WKInterfaceDevice currentDevice] cachedImages] dictionary to find the size of the cached image data. The dictionary returns a NSNumber with the size (in bytes) of the cache entry.
I just discovered that if you use this line of code:
[self.image setImageNamed:#"number"]
Your images should be named:
number1.png
number2.png
number3.png
number4.png
I was running into a similar error when I had my images named:
number001.png
number002.png
number003.png
number004.png
I am creating an app which uses sockets to send data to other devices. I am using Http protocol to send and receive data. Now the problem is, i have to stream a video and i don't know how to send a video(or stream a video).
If the user directly jump to the middle of video then how should i send data.
Thanks...
HTTP wasn't really designed with streaming in mind. Honestly the best protocol is something UDP-based (SCTP is even better in some ways, but support is sketchy). However, I appreciate you may be constrained to HTTP so I'll answer your question as written.
I should also point out that streaming video is actually quite a deep topic and all I can do here is try to touch on some of the approaches that you might want to investigate. If you have control of the end-to-end solution then you have some choices to make - if you only control one end, then your choices are more or less dictated by what's available at the other end.
If you only want to play from the start of the file then it's fairly straightforward - make a standard HTTP request and just start playing as soon as you've buffered up enough video that you can finish downloading the file before you catch up with your download rate. You don't need any special server support for this and any video format will work.
Seeking is trickier. You could take the approach that sites like YouTube used to take which is to simply not allow the user to seek until the file has downloaded enough to reach that point in the video (or just leave them looking at a spinner until that point is reached). This is not the user experience that most people will expect these days, however.
To do better you need to be in control of the streaming client. I would suggest treating the file in chunks and making byte range requests for one chunk at a time. When the user seeks into the middle of the file, you can work out the byte offset into the file and start making byte range requests from that point.
If the video format contains some sort of index at the start then you can use this to work out file offsets - so, your video client would have to request at least enough to get the index before doing any seeking.
If the format doesn't have any form of index but it's encoded at a constant bit rate (CBR) then you can do an initial HEAD request and look at the Content-Length header to find the size of the file. Then, if the use seeks 40% of the way through the video, for example, you just seek to 40% of the way through the encoded frames. This relies on knowing enough about the file format that you can calculate an appropriate seek point so that you can identify framing information and the like (or at least an encoding format which allows you to resynchonise with both the audio and video streams even if you jump in at an arbitrary point in the file). This approach might also work with variable bit rate (VBR) as long as the format is such that you can recover from an arbitrary seek.
It's not ideal but as I said, HTTP wasn't really designed for streaming.
If you have control of the file format and the server, you could make life easier by making each chunk a separate resource. This is how Apple HTTP live streaming and Microsoft smooth streaming both work. They need tool support to pre-process the video, and I don't know if you have control of the server end. Might be worth looking into, however. These also do more clever tricks such as allowing a client to switch between multiple versions of the stream encoded at different bit rates to cope with differences in bandwidth.
I am using the below jQuery plugin for playing mp3
www.happyworm.com/jquery/jplayer
However, there is a bug in Flash that the total play (track) time won't show up correctly UNTIL AFTER the whole mp3 is completed downloaded.
I wonder if there is a way to work around this to get the correct total time using either javascript / another flash / even backend library in ASP.NET. Any suggestion helps. Thanks
You sure that's a bug? Looking at the header definition for the MP3 format I don't see any values for the length of the file. Generally applications that play MP3s would have to calculate the time, and that may not be doable until the entire file is downloaded. So the behavior you're seeing from Flash might be expected.
Theoretically if it's a fixed bitrate file (as opposed to VBR) then knowing the bitrate (gotten from the header) and the total size of the file should be enough to calculate it. However, the server would have to report the size of the file in the response headers (and that's not guaranteed to be accurate).
My guess is you'd need some service on the server that could calculate the length and report that to you in a separate request.