I have written this code to make my page load faster by loading smaller resolution picture depending on their resolution...
window.onload = function() {
bannerRes();
function bannerRes() {
var x = $(window).width();
var y = $("#banner");
if(x<=1920) {
y.css('backgroundImage', 'url(team_banner_1920.jpg)');
} else {
y.css('backgroundImage', 'url(team_banner_2560.jpg)');
};
};
$(window).resize(function() {
bannerRes();
});
};
But I'm not sure if it's worth using or if any issues could come up with it. Any opinions please? Thank you
It looks like you are implementing an Adaptive Image solution.
Much discussion on this topic is taking place in the W3C, so be advised that the "experts" are looking into this topic.
The situation gets trickier if you are delivering to iOS Retina display on mobile devices. Because they require 'double-density'. And effectively double your image maintenance, and JS code to maintain the experience cross-device.
The problem is that this can become a maintenance nightmare if you have to update your code, a few years from now, for every new device that may come out.
The initial solution to this is to use #media-query which will give you the capability to maintain the images in your css, and simplify your JS.
An interesting topic that is pending W3C is a <picture/> tag that would give responsive capacity at the dom attribution level. Thus avoiding both, css and JS footprint. But this remains to be seen at this point.
Hope that helps.
Only you can tell if it is worthwhile.
It is well known that Google factors page load speed into its ranking algorithms, so if this is your concern then it could be effective.
Is there a lot of traffic to your site? Is it likely that users will have lots of different screen reolutions? Can you infer anything like that from your site stats - i.e. do you have hits from a wide ditribution of screen resolutions?
So, in short its not really possible to answer here. If you gave more specifics on the site then it may be possible to infer, but even then you're better off trying some metrics yourself.
You could try image resizing with jquery's animate... then you'll have only one image on the server, and you can resize it accordingly...
This question has the answer on how to do it...
Related
This is not really a answer I NEED but it is more of a curiosity for me. I personally make my webpages dynamically by checking screen size then create my divs from that size. Now what would be the benefits of a 'static' sizing(like using px) over my method?
The obvious answer would be the benefits to control over your design. Plus, by generating your pages' content entirely on the fly, you're making the (usually, but not always safe) assumption that your uses have javascript enabled. Without a fallback default, what are those non-JS users going to see?
Personally, I'd opt for making large-scale adjustments based on screen/window sizes that fall within a range. That way you're not having to dive into the DOM every time a user adjusts their viewport, plus, as I said earlier, you've got a great deal more control over how your content is presented.
Just my two cents...
I determine which stylesheets I send to the browser based on the size of the window and type of device - but they are fixed width pages. I personally find it very difficult to write good looking websites that scale well and look good on both low and high resolution screens. Keeping control of 2 or 3 different "sizes" is much easier for me.
Waiting for javascript execution also delays the time that users can start reading your content, and is not always desirable.
And sometimes an art designer would actually do that layout designs, where you just put in the vital codes to make things work... And they happen to use a lot of static image sizes for decoration...
Accessing dom can be slow and expensive, for some pages that I just want to see the content fast and clear, maybe all those resizing really isn't necessary.
I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.
I get the same problem on both iPhone and iPad.
What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?
I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.
The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?
So the bottom line is: -webkit-transition crashed the page on mobile safari.
Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.
I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:
As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.
However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.
The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.
Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.
In any case, to give more up to the point suggestions, more information about your page would be really great.
By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:
General
About
Diagnostics & Usage
Diagnostics & Usage Data
If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).
Otherwise, it might tell you what is wrong...
Hope this helps.
There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.
See Apple's documentation for more info.
I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.
I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).
After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.
Adding a little timeout solved the problem. My application was also using iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});
I'm working on a HTML 5 game, it is already online, but it's currently small and everything is okay.
Thing is, as it grows, it's going to be loading many, many images, music, sound effects and more. After 15 minutes of playing the game, at least 100 different resources might have been loaded already. Since it's an HTML5 App, it never refreshes the page during the game, so they all stack in the background.
I've noticed that every resource I load - on WebKit at least, using the Web Inspector - remains there once I remove the <img>, the <link> to the CSS and else. I'm guessing it's still in memory, just not being used, right?
This would end up consuming a lot of RAM eventually, and lead to a downgrade in performance specially on iOS and Android mobiles (which I slightly notice already on the current version), whose resources are more limited than desktop computers.
My question is: Is it possible to fully unload a Resource, freeing space in the RAM, through JavaScript? Without having to refresh the whole page to "clean it".
Worst scenario: Would using frames help, by deleting a frame, to free those frames' resources?.
Thank you!
Your description implies you have fully removed all references to the resources. The behavior you are seeing, then, is simply the garbage collector not having been invoked to clean the space, which is common in javascript implementations until "necessary". Setting to null or calling delete will usually do no better.
As a common case, you can typically call CollectGarbage() during scene loads/unloads to force the collection process. This is typically the best solution when the data will be loaded for game "stages", as that is a time that is not time critical. You usually do not want the collector to invoke during gameplay unless it is not a very real-time game.
Frames are usually a difficult solution if you want to keep certain resources around for common game controls. You need to consider whether you are refreshing entire resources or just certain resources.
All you can do is rely on JavaScript's built in garbage collection mechanism.
This kicks in whenever there is no reference to your image.
So assuming you have a reference pointer for each image, if you use:
img.destroy()
or
img.parentNode.removeChild(img)
Worth checking out: http://www.ibm.com/developerworks/web/library/wa-memleak/
Also: Need help using this function to destroy an item on canvas using javascript
EDIT
Here is some code that allows you to load an image into a var.
<script language = "JavaScript">
var heavyImage = new Image();
heavyImage.src = "heavyimagefile.jpg";
......
heavyImage = null; // removes reference and frees up memory
</script>
This is better that using JQuery .load() becuase it gives you more control over image references, and they will be removed from memory if the reference is gone (null)
Taken from: http://www.techrepublic.com/article/preloading-and-the-javascript-image-object/5214317
Hope it helps!
There are 2 better ways to load images besides a normal <img> tag, which Google brilliantly discusses here:
http://www.youtube.com/watch?v=7pCh62wr6m0&list=UU_x5XG1OV2P6uZZ5FSM9Ttw&index=74
Loading the images in through an HTML5 <canvas> which is way way faster. I would really watch that video and implement these methods for more speed. I would imagine garbage collection with canvas would function better because it's breaking away from the DOM.
Embedded data urls, where the src attribute of an image tag is the actual binary data of the image (yeah it's a giant string). It starts like this: src="data:image/jpeg;base64,/9j/MASSIVE-STRING ... " After using this, you would of course want to use a method to remove this node as discussed in the other answers. (I don't know how to generate this base64 string, try Google or the video)
You said Worst scenario: Would using frames help, by deleting a frame, to free those frames' resources
It is good to use frame. Yes, it can free up resource by deleting the frames.
All right, so I've made my tests by loading 3 different HTML into an < article > tag. Each HTML had many, huge images. Somewhat about 15 huge images per "page".
So I used jQuery.load() function to insert each in the tag. Also had an extra HTML that only had an < h1 >, to see what happened when a page with no images was replacing the previous page.
Well, turns out the RAM goes bigger while you start scrolling, and shoots up when going through a particularly big image (big as in dimensions and size, not just size). But once you leave that behind and lighter images come to screen, the RAM consumption actually goes down. And whenever I replaced using JS the content of the page, the RAM consumption went really down when it was occupying to much. Virtual Memory remained always high and rarely went down.
So I guess the browser is quite smart about handling Resources. It does not seem to unload them if you leave it there for a long while, but as soon you start loading other pages or scrolling, it starts loading / freeing up.
I guess I don't have anything to worry about after all...
Thanks everyone! =)
I'm showing images from other websites as thumbnails. To do this I display them in a smaller img tag so the browser does the size decrease.
The problem is that the quality of these images (which I have no control of) is diminished.
Also they look much better in FF and Safari than in IE.
Is there a way to make these images look better without caching them on my server? (e.g a javascript library that does the resize with better quality)? Any idea is highly appreciated.
IE's default image resizing algorithm is not that nice - it can be changed by tweaking a registry entry, but of course that is outside of your control.
However, apparently it can also be triggered to do a better image resize through css
img { -ms-interpolation-mode: bicubic; }
source: http://edmondcho.com/blog/2009/03/17/internet-explorer-image-resizing-tip/
A quick Google search shows that in IE7 you can fix the image quality problem:
http://devthought.com/tumble/2009/03/tip-high-quality-css-thumbnails-in-ie7/
The only way to have control is to do the resizing yourself. Various browsers will use different algorithms, some with unsharp masking, some without. The filters used after resizing control most of this. Specific CSS tagging can control this to some extent.
Javascript can't really handle this, but using Flash or similar would allow this. You would have better control of the image. However, you would lose the "imageness" as far as HTML.
One thing I didn't see mentioned by the others - you aren't really resizing the image, you are just displaying it in a smaller space. Let's say you are pulling down an extremely large image file (5MB) and displaying it at 1 x 1 - it's still 5MB!
Writing a caching solution for these images wouldn't be very difficult at all - and will save you the legal ramifications and embarrassment. If I saw your site in my log files and realized you were pulling down my images, you would be Goatse'd - hard.
If you are working with a source image and simply re-sizing on the client, there isn't going to be a good way to do this.
Now, aside from the potential legal ramifications of using other sites images you could look at a simple caching process, and do a quick re-size on the image, and keep the aspect ratio, so that the display is good. This also helps reduce the bandwidth that you are using from the other sites.
I'm doing some animations and I want to implement something like this on the web. I was thinking that the HTML canvas can do this kind of job. Because I can scale part of an image. I just need the algorithm to actually make it work.
The effect is elastic, if the window is small, the greater the elasticity of the window when you restore it. I was thinking that I can make this work in web images.. if the user click the image it will scale with this kind of effect, not the boring way of scaling.
This is ubuntu, I know that we can look at the source code maybe to see how it actually implements the animation. But I dont know where to find it. Or i don't even understand codes written in linux because I just understand php, javascript. Basically I'm not a software developer, My core expertise is in web development.
http://www.youtube.com/watch?v=hgQP-aFragQ
I believe your best bet is having a look at John Resig's Processing.js.
Processing is a animation language for Java; John has ported it to the browser using canvas.
Your not going to find a web based solution that is going to do this for you. If you need something like this done it will have to be in flash or some other application (Lenni mentioned Java) that runs in a separate media box embedded in a web page.
People don't want big flashy animations, seeing something that is 'boring' is much better if it becomes more usable.
First up - I don't know the actual algorithm they use here.
However, I'd attack this by creating a grid of points (say 10x10), each point attached to it's neighbors by damped springs. It might be worth anchoring the edge/corner points to the screen with springs too.
By deforming the grid (stretching and compressing the springs) and then modeling the spring responses, you'd get some interesting effects like those shown. You might then be able to record the patterns so that the points can follow a pre-computed path for faster animation if your animations are predictable.
Then you need to work out how to split the image and map it onto the grid. The splitting may be better done once on the server, but the client can do it if you use canvas.
svg & vml is a possibility - they'll work without plugins and are similar enough to code for, but I don't think you'll get correct enough image deformation. However, you can scale and rotate with impunity (and quickly) so if you just anchor 2 cell image points to the grid rather than all 4, you'll get an interesting animation - not quite like the video, but pretty good.
As for how to model damped springs, you'll need to keep track of the mass of each point (how heavy it is), how much force the spring is exerting on each point (scalar of how compressed/stretched it is and it's vector) and a damping force on the points (resistive force to the square of the velocity of the point).
It's physics modeling, to be sure, but quite possible.
The response may well be slow. Especially on IE. Canvas needs a plug-in on IE, so if you use canvas, IE folk wont see it. SVG works on almost everything except IE, but it does have VML which is similar. http://raphaeljs.com/ is a library that uses whatever's available. This will be a challenge to tune up :)
However you do this, it will always look best in chrome, the V8 javascript engine outstrips everything else for this kind of work. IE has the slowest javascript engine.