homepage Welcome to WebmasterWorld Guest from 54.205.106.111
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
Forum Library, Charter, Moderator: open

JavaScript and AJAX Forum

    
Hosting jquery slideshow in a iFrame
Nika




msg:4626022
 8:37 am on Nov 26, 2013 (gmt 0)

my site loads slowly. There are some cufon fonts and some font-face that I'm using and can't do without them. That slows things down as it is. Narrowed font-face fonts as much as I could, but still...

On top of that there is a jquery slideshow that fetches a bunch of hefty javascript files and an additional css file, as well as not too light images. It is just a slideshow, no links or any other functionality.

I'm thinking, maybe I could run this slideshow on a different domain, put all javascript and images and css there,and output it on my site in a iFrame. I'm wondering if I gain something in performance this way? Wouldn't care if the slideshow loading will be lagging a little...

 

rainborick




msg:4626075
 3:13 pm on Nov 26, 2013 (gmt 0)

Storing your slideshow images on a different domain/hostname is a good idea, but using an <iframe> is not going to speed things up. The browser still has to deal with all of the same components of your page, so it would essentially just be adding another HTTP request into the mix.

You can also include the smaller, single-purpose JavaScript and CSS files in the parent HTML document. Make sure your images are reasonably well-compressed. Enable GZIP encoding for HTML, JavaScript, and CSS files on your server. There are a lot of speed-ups that you can use. Check out Google's PageSpeed Insights tool. It will test the loading speed of any URL and diagnose problem areas.

JD_Toims




msg:4626624
 9:45 pm on Nov 28, 2013 (gmt 0)

The browser still has to deal with all of the same components of your page, so it would essentially just be adding another HTTP request into the mix.

True, except that browsers usually default to N [2 last I checked] connections per hostname, so by moving the files to a different hostname [even a different sub on the same main domain] you can force a browser to open N*2 more simultaneous connections and get an overall speed increase, especially with scripts, since the downloading of any/everything else stops until the script is completely downloaded.

phranque




msg:4626656
 6:07 am on Nov 29, 2013 (gmt 0)

have you run any site speed tools to understand exactly what is causing your issues?

Nika




msg:4626670
 9:29 am on Nov 29, 2013 (gmt 0)

Yes, Google speed checker... there was a list of issues which came down pretty much to cufon and javascripts that service the slideshow after I fixed everything else. According to the test these are "blocking javascripts", whatever it means.. I'm gonna try the iframe and report here about improvements if I observe any.

Nika




msg:4626677
 9:45 am on Nov 29, 2013 (gmt 0)

As for rainborick's advice, I did mostly all of that I think. There is also a technique suggested by the package vendor (as I'm using supposedly a turnkey package) that would speed up the Mysql database, but it comes with bunch of exclamation signs meaning that using it without really knowing what exactly is u are doing will surely ruin the whole thing... At this moment I'm counting on the additional connection idea like JD_Toims is suggesting. Let's see.

JD_Toims




msg:4626825
 11:07 pm on Nov 29, 2013 (gmt 0)

Something I've had to do to "find speed" in the past is "juggle" where things load from.

So, you request the iFrame from a different hostname, essentially forcing two extra connections -- If you have a bunch of JavaScript loading via that hostname though, it'll only be one extra connection that's used and one file at a time will be downloaded when there's a script requested, but there will still be 2 connections used by the main hostname, so if by moving the scripts, etc. to an iFrame, you speed up your load-time on your main page, a test I would run is something like:

Load the iFrame from the other hostname.
Load all JS files via the iFrame and from the other hostname.
From within the iFrame on the secondary hostname, request the images from the main hostname and see if that's faster or slower than if you request the images from the secondary hostname.

EG

www.example.com loads the "base page" and has the iFrame on it with the source as includes.example.com.

Then the iFrame has the JS file request on it and they're also loaded via includes.example.com, so a browser will only use one connection to includes.example.com every time it finds a script source and will completely load/process the script before it requests anything else from includes.example.com.

-- Depending on the order of things, size, number of scripts, etc. it might be faster to load the images on the iFrame page from the www hostname, so I'd probably test both ways, meaning on the iFrame I'd code all the <img src="http://includes.example.com/the-path/to-the-images.ext"> dump the cache on a couple browsers and load the main page -- Then on the iFrame I'd change only the images to <img src="http://www.example.com/the-path/to-the-images.ext"> dump the caches and try again.

There are times when I've found a very noticeable difference [meaning visibly twice as fast] in overall load time by getting the combination of when things are requested in "the right order" and where they're coming from as "the right hostname".

I should also note, in testing I've found using 3 hostnames to try and force 6 [or whatever] connections is usually *counter productive* and slows things down overall, but there may be cases where a large number of scripts are being loaded, which limits the connections used to one per hostname where 2 other hostnames in addition to the main hostname is beneficial -- The only way to really know if that's true in any given situation though is to test different combinations.

BTW: I may not be explaining things very well, so please just stick with the main point of: "multiple hostname use", "load order" and "the right combination" from each hostname can make a very noticeable difference in overall load-time by forcing a browser to use more connections -- These changes may not be evident in speed-testing tools, even if they're noticeable in browsers -- IMO tools are nice to have as a resource, but the bottom line for me is: how fast is it for "real people", not how high do I score on the tool.

Nika




msg:4630609
 5:35 am on Dec 14, 2013 (gmt 0)

Eventually it did load faster, indeed, via opening extra connections... Not that the viewers were flabbergasted at once, but there is a noticeable difference.

Nika




msg:4636631
 1:45 am on Jan 11, 2014 (gmt 0)

Didn't want to start a new thread since it may not be an important subject... asking here therefore.

My site is slow, as you could already guess... I identified some reasons of which fixed some while others can't be fixed. What's bothering me at the moment is that it seems that as it loads the site goes into some process that doesn't resolve and continues only after some kind of a TimeOut. It certainly feels like the timeout. Had a similar thing before when it was trying to resolve urls written in some unicode and waited for the timeout.

So, the question is whether there are any tools that would tell me what processes are being loaded exactly and in what sequence so I could identify the reason for the timeout waiting if there indeed occurs any. The online speed tests aren't good for this obviously. There is such thing as LoadUI, but I have trouble trying to launch it on ubuntu lamp. Is there anything else of that sort?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved