I'm making finishing touches on my site and am struggling to make the load of the page look less jumpy. best way to show you what i mean is to show the site:
http://marckremers.com/2011 (Still not complete, in alpha phase)
As you can see the contents sticks to the left, loads a ton of jquery and images into the page, and only then click into place (centre).
I'm wondering if there is a way i can make it click into place first and then load the elements?
I tried putting the reposition script just after , not even that works.
Any ideas? Thanks
With all of the images you have, your page is 1.5mb, coupled with 70 http requests. No wonder your site behaves the way it does.
You should be using sprites on the smaller images to reduce http requests and as far as the large images go, you are loading all of the pictures at once. Even the ones that aren't displayed right away. The images that aren't displayed right away should be pulled in via AJAX after the page loads.
If you want to go further into optimization I would also:
Use one external javascript file. Yes
it increases size, but I favor that
over http requests.
Minify your html/javascript/css.
Don't host jQuery on your site, use a CDN such as Google APIS.
Check out a service similiar to Amazon S3.
I could reinvent the web site best practices wheel here, or I could send you to Yahoo best practices for web site optimization There is a ton of very important information there, read it and reference it.
You loaded jQuery twice, once from your own site and another time from Google's CDN. For starters, you should probably move all the JavaScript to the bottom of your HTML. Then you need to optimize your if ... else that handles how many columns to display and your Google Maps iframe.
To speed the visual up, instead of using jQuery, you should probably have some vanilla DOM scripting that dynamically creates some CSS styles for the projects and tb_tweets classes, so it doesn't have to wait for all your JavaScript to load before handling resizing of your projects and tb_tweets.
use http://mir.aculo.us/dom-monster/ and do everything it tells you to do. If you want tools to figure out what is going on during page load, the chrome developer tools are hands down the best out there for client side optimization.
A think you could do is put your javascript functions in the document.ready(function()), this way the functions will be loaded AFTER the page is loaded. I guess you don't need the functions for loading the site, just to interact with it?
Generally you only want to trigger your events after the page has rendered, i.e., using
$(document).ready(function()) {
//your javascript goes here
}
Then, in your HTML you have placeholders so the page doesn't "expand" or "jump" as you put, with some kind of indication that the element is still loading. Then, when your ajax requests complete, simply populate the placeholders with the ajax response.
Related
I am trying to create a small frame on my site that will show the home page of another site similar to what google is doing with your most viewed pages. I know how to create this with frames but I am really against frames in general for many reasons not worth mentioning. Is there a jQuery plugin somewhere that can do that for me?
For a more visual explanation go here and navigate to 'portfolio'. The current developer is using simple images for what he is doing. I would like those icons to be frames of other sites instead
You want an actual image of a webpage? You'd need something like html2canvas, but that'll be html5 only. There's some methods for doing this in PHP as well, but it's tricky, and I've only heard of this in theory, never actually practiced it myself.
How about this link?
Website screenshots using PHP
To embed an external page within your page, you should check out the <iframe> tag.
As pointed out in the other answer absolutely the best solution to embedding an external site into yours is usually an <iframe>.
You could, in theory, avoid using <iframe>s by pulling in the HTML from the external sites via ajax requests and injecting it into your page, as appropriate, using javascript. This is a much more heavyweight solution however and I wouldn't recommend it to solve your particular problem, but just to point it out.
What I would recommend however is just linking to the sites, potentially with target="_blank" so that the links don't send the browser away from your portfolio.
<iframe>s have their place for certain solutions, but for browsing the different sites you've worked on? No - I'd say the user would benefit from the full browser window experience for that.
On a website, I'm experiencing a "flash" of white that occurs between page loads. It looks bad because I'm using a background image and when the page loads, the background images flash before it comes onto the screen (take a look for yourself). This issues occurs in chrome and IE but not in firefox.
The site has a way of preloading stuff. Every element on the page is in a div wrapper #website which is initially at display:none, and every image is in a div wrapper #website-images which is also hidden. Then the site (using a jquery plugin) checks to see if all the images in #website-images are done loading, once they are a cookie is set to remember that this user has loaded the images already so it won't go through the preloading process once they go to another page or reload the current one, then a call to $("#website").show() is made to display the webpage.
So what could be causing this flickering between the page loads? Is it my way of preloading images? I've added different doctypes, and changed meta information but NOTHING has worked. I'm really lost here, does anyone have any ideas or insights?
This is happening because the DOMLoaded event is fired enough milliseconds before the page actually renders.
In a nutshell, this means you have to optimise your website's speed. This doesn't mean to make it download faster, but it means to download in the correct order, in a non-blocking way.
Step one: Your markup
1)
It seems there is a lot you can do to optimise your markup. Firstly, the order of stylesheets and JavaScripts can be optimised. To ensure CSS files are downloaded asynchronously, you always have to include external CSS before external JavaScript files. style.css is downloaded after some/all of your JavaScript calls.
There is 1 script block found in the head between an external CSS file and another resource. To allow parallel downloading, move the inline script before the external CSS file, or after the next resource.
2)
Your main JavaScript file is inline within your markup. Not only does this block the page download until the script has finished downloading, but having it before your content is probably causing (or adding to) the white flash.
Loading your script asynchronously in the head is my preferred method. You will then have to trigger your script when the DOM has finished loading, or you can achieve the same result by placing the script at the bottom of the body tag.
Step two: Harness the browser's capabilities
1) Looking at the http headers, there are 28 items being served as separate HTTP calls, that are not being cached on the browser (including the html pages, jpg images, stylesheets and JavaScript files).
These items are explicitly non-cacheable, and this can be easily fixed by editing your webserver's configuration.
2) Enable gzip compression. Most web browsers (yes, even IE) supports gzip decompression, and most (if not all) web servers support compressing using gzip. You could even go overkill and look into SPDY, which is an alternative lighter HTTP protocol (supported in Chrome and Firefox).
Step three: Content serving
There are around 30 individual items being served from your domain. Firstly, consider how you could reduce this number of requests. 30 HTTP requests per page view is a lot. You can combat this using the following methods:
1) Paralleled downloads across multiple hostnames. Browsers currently limit the number of concurrent connections to a single domain. Serving your images from a separate domain (for example, img.bigtim.ca) can allow them to be served in parallel to other content.
2) Combine multiple items into one. Many items that are downloaded are purely style content, such as the logo, menu elements, etc. These can be combined into a single image (downloaded only once), and split using CSS. This is called CSS spriting. Stack Overflow does this: look here.
3) If you cannot reduce the amount of items needing downloading, you could reduce the load on your server (and in turn, the client's browser) by serving static content from a cookieless domain. Stack Overflow does this with all their static content such as images, stylesheets and scripts.
Step four: Optimise your own code
There's only so much that HTTP and browser technology can do to help your website's speed. This last step is down to you.
1) Is there any reason you choose to host jquery yourself? Jquery's download page shows multiple CDNs where you can point to for speedy, cached script downloading.
2) There are currently over 20 unused CSS rules within your stylesheets (that's 36% of your entire CSS file). Have a re-think of what is really needed.
3) The main chunk of JavaScript (at the top of your body tag) seems to be a hack to attempt to speed things up, but is probably not helping anything.
A cookie is being set to specify whether or not the page has faded in yet. Not only are you using JavaScript to perform a transition which can happily be performed by CSS, but more than half of the script is used to define the functionality for reading and writing the cookie.
Seeing things like this: $("body").css ("background-image", "url('images/background.png')"); and $("#website").show (); usually gets me ranting about "separation of concerns", but this answer is long enough now so hopefully you can see that it is bad practice to mix style and functionality in the same code.
Addendum: Looking at the code, there is no need for jquery at all to
perform what you are doing. But then again, there is no need to
perform what you are doing, so you could probably do better without any
JavaScript at all.
Move your javascript to the end of the html just before closing the body tags. Sometimes it helps.
I know this is old thread but here is a hack I tried and works.
The idea is not to display anything while CSS is loaded completely.
in html file:
<body style="display:none">
in your CSS, the last line:
body{display:block !important}
CSS is render-blocking.
Divide you CSS into 2 parts -
Critical CSS
Non-Critical CSS
Make Critical CSS load with the page. It should come embedded within the head tag.
Make Non-critical CSS lazy load via ajax.
This will result in serious performance optimization in your webpage leading to less white-screen time.
Also, you can consider loading your Javascript in async/defer way.
I want to make a javascript (or jQuery if that's a possibility) button for my HP which stops the loading of the images on the page (for example when a user has to pay per MB and is only interested in the text).
I searched and searched and found answers like "remove the src", or "use window.stop()", but the problem is that they don't work, cancel the whole loading process, or simply don't do what I had in mind (like removing the images completely).
Does anyone know how I could achieve that?
Thank you very much :)
PS.: found a how to that claims that it can stop the download of specific parts of the site, but it doesn't really explain how to specify the part. I don't get how to link things here so here's the url: http://www.ehow.com/how_6104889_kill-browser-downloads-javascript.html
Thanks again.
Short answer: don't bother. If a user has such limited bandwidth that loading images is a problem, they will have disabled images anyway, or they will use some mechanism to load images on demand. You don't want to burden users with a non-standard solution that only works on your homepage. Simply put, it is not your problem.
Long answer: you can use placeholders instead of actual images on the initial page load, and then use Javascript to set the src attributes one by one, having each successful load trigger the next image. You will lose parallel loading though, which means you are punishing high-bandwidth users (which is the overwhelming majority these days) with much longer loading times, and you'll be spending a lot of effort on a feature that is (see short version) mostly useless.
You could try to change src to point to an empty image.
You won't be able to cancel the image loading process programmatically from within the web page.
You could try breaking all image srcs using JavaScript but it's a dirty approach, and your results may vary - it could be that the browser continues to load the resource nevertheless.
The best way to go would probably be either loading images on demand (which is possible to do from within the page), or offer the option of serving pages from server side that don't contain the images in the first place.
However, as #tdammers correctly points out in his answer, it's probably best not to bother. People on a traffic quota will take their own precautions against loading too much content.
I wouldn't bother replicating a browser configuration option with an in-page button, but I would recommend showing a placeholder image then lazy-loading the images for mobile users.
Also as you like JQuery, there are jQuery Lazy-Loading plugins out there.
What are the real benefits (if any) to loading your JS at the bottom of the document, as opposed to the top. It seems there is a brief delay in page loading and JS dependent functionality.
I am using html5boilerplate for beginning all my templates, but am not really sure on how beneficial loading the JS at the bottom is.
Does it really make all that much of a difference, and if so, why?
If you include external js files at the bottom of your page, you give the priority of your HTTP requests to the visual display that will be presented to the client instead of to the logic of interaction or dynamics. I believe, if you do not use a content delivery network to deliver images to the client then you are only allowed to process a maximum of 2 HTTP requests at a time. You do not want to waste these requests on logic because we all know how impatient the end user is.
By loading js at then end of the file you can access the DOM(most of the time) without having to call a document.ready() function. You know that if the page render finally makes it to your javascript code that the necessary page elements have usually loaded already.
There are a few more reasons out there but these are the important ones that I try to remember when it feels so awkward to place all js at the bottom.
As scripts that are referred to are being downloaded, browsers typically won't download other files in parallel, thus slowing the page load.
refer: Best Practices for Speeding Up Your Web Site
A Google search will return a large number of results as to why you want to do so and what improvement you'll see. Check out some of these following links:
High Performance Web Sites: Rule 6 - Move Scripts to the Bottom
Rails Best Practices: Scripts at Bottom
Basically, the main reason for doing so is that you'll improve render times of your page. From the first article:
[I]t’s better to move scripts from the
top to as low in the page as possible.
One reason is to enable progressive
rendering, but another is to achieve
greater download parallelization.
depending on what is in the js. if only want it to 'go' when the page loads either surround your code by jquery's: $(function(){}) or place it at the bottom of the page
I was just using the plugin "Yslow" for Mozilla Firefox, and it told me that I should put JavaScript at the bottom. I have heard this before but haven't really thought about it too much. Is there really an advantage in putting JavaScript at the bottom of a web page compared to the top?
It'll allow the web page to load visibly before executing JavaScript, which makes sense for things like Google Analytics, which don't need to happen before the page loads.
You may also want to look into things like jQuery, prototype, etc and attach to the "ready" handler, which executes JavaScript code after the DOM has been fully loaded, which is an appropriate place for much JavaScript code.
Assuming you aren't running on a CDN or aren't serving your JS from a separate sub-domain or server, it will load synchronously and force your HTML content to wait until it has downloaded the files. By placing the JS at the bottom of your page before the closing </body> tag, you are allowing the HTML to be parsed prior to loading the javascript. This gives the effect of faster page load times.
If you have static html content and a lot of javascript, it can make a difference in perceived page load time since the html will load first giving the user something to look at. If you don't have much javascript, or the existing page content relies on the javascript to be useful, then this is not as useful practically-speaking.
I want to bring update to this topic, google has recently introduced async snipped http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080&rd=1 which can be added for your site to bring e.g. google statistics support. It should be placed bottom of the <head> section for best performance. The point is that this increases likely hood of tracking beacon to be sent before user leaves the page.
Also it should be located there if you want to verify your site in google webmaster tools using your google analytics.
Other than that, same rules still applies basically - javascript at bottom for "fast" loading of the page. I used quotes because I dont count page fully loaded until javascript finishes ;-)
Yes, the page will load the content and render it before loading and executing javascript, and the page will, as a result, load faster.
TOP
When you put your JavaScript at the top of the page, the browser will start loading your JS files before the markup, images and text. And since browsers load JavaScript synchronously, nothing else will load while the JavaScript is loading. So there will be a timeframe of a few seconds where the user will see a blank page, while the JavaScript is loading.
BOTTOM
On the other hand, if you place your JavaScript at the bottom of the page, the user will see the page loading first, and after that the JavaScript will load in the background. So if, for example, your CSS & HTML takes 5 seconds to load, and your JavaScript takes another 5 seconds, putting our JavaScript on the top of the page will give the user a “perceived” loading time of 10 seconds, and putting it on the bottom will give a “perceived” loading time of 5 seconds.
Taken from Demian Labs.
It allows all the DOM elements to fully load before loading the Javascript which addresses them. This standard is also part of Visual Studio.
Placing scripts at the bottom of the element improves the display speed, because script compilation slows down the display.
Yes including the javascript at the bottom of the page really quickens the loading of the page. Since browser executes things synchronously it impacts the page loading if it is placed at the top of the page. If it is placed at the bottom of the page, the page would have loaded the entire markup by then when the browser starts loading the javascript giving a better experience to the user.
It's advisable to put all inline scripts at the end to improve performance, you don't want your users to be staring at a blank white screen while the script renders. You can use defer attribute eg. to prevent link scripts from delaying your html rendering.