Slow site... but just in Chrome/Safari

views:

answers:

Slow site... but just in Chrome/Safari

I'm trying to find a bug in a web application, which is causing Chrome and Safari to take up to 15 seconds to load the page (Firefox and IE, there are no problems). I've tried using Chrome's developer tools to find out what is causing the slowdown, but am unable to understand what elements/script is slowing down the page.

This is a joomla site with a custom add-on (done by another developer, not myself)... looking for some help in diagnosing the problem.

The URL is http://www.norfolktourism.ca/index.php?option=com_eventlist&view=eventlist&Itemid=70

Without showing us any code / script we can't really help much. One thing I can recommend is begin with one panel and keep a dding to determine the root cause of this.

My instincts tells me it is the image loader as this may have some JS bug. Top right corner remove that and try to load the page in chrome. If you notice it is a lot quicker you know that is your issue.

JonH 2010-07-15 13:01:01

+1 A:

I've tried loading the page with javascript disabled in chrome, and it's still super slow. Using Chrome's developer tools, I see 25 messages showing "XML self-closing tag syntax used on . The tag will not be closed.", followed up by a "[ Exception: TypeError: Expecting a function in instanceof check, but got TypeError: Cannot read property 'ANY_TYPE' of undefined ]".

There do seem to be quite a few div tags that are self closing; while it shouldn't cause problems, it can't hurt to clean them up.

El Yobo 2010-07-15 13:07:08

Other's have also had the problem reported; <div /> is apparently invalid - http://code.google.com/p/joomla-gcalendar/source/detail?r=822

El Yobo 2010-07-15 13:15:51

Not to mention that XHTML is dying a slow death. W3 is no longer evolving the spec: http://everythingisgray.com/2009/07/02/xhtml-is-dead-but-dont-worry/Ok, so not dead, but it makes sense to go over to html 4.01 strict while we wait for html5 support....regardless, no more self-closing tags. Woot!

bpeterson76 2010-07-15 19:13:16

Turns out that this was the problem. Somehow, a <div> was opened, and was never closed.I love other people's code...

MetalAdam 2010-07-15 19:51:17

+1 A:

I recommend you to try some chrome extensions:

Firebug Lite: https://chrome.google.com/extensions/detail/bmagokdooijbeehmkpknfglimnifench
Speed Tracer: https://chrome.google.com/extensions/detail/ognampngfcbddbfemdapefohjiobgbdl

I think firebug is better than default chrome's developer tools. And speed tracer can be quite useful to track items that are taking too much time to load.

Alexandre 2010-07-15 13:08:04

+1 A:

Some advices:

Save the background image and every image that appers in the header in the png format to decrease their size
Try to enable the gzip because the html content weights too much
Use Chrome developers utilities to analyze every request that is done on the page to understand what is slow

UPDATE: Try to remove the addthis_widget.js script, it loads a lot of resources and it adds an hidden iframe that slows Chrome

mck89 2010-07-15 13:08:35

PNG format won't necessarily give you the lowest file size. Image optimization is more complicated than that, and while I don't completely understand it, I usually go by trial and error until I find the best compromise of file size and quality.

Ryan Kinal 2010-07-15 13:12:19

Doesn't JPEG usually compress better than PNG? Unless you can use PNG-8 and make them *really* small.

Svish 2010-07-15 13:13:06

Yes you're right after that you must find a good compromise with size and quality, but i always prefer png because they preserve a good quality also with low size. Anyway the problem of the loading time is certainly caused by the size of the page.

mck89 2010-07-15 13:18:22

If it's only happening on webkit based browsers like Safari and Chrome, it's probably _not_ caused by the size of the page.

El Yobo 2010-07-15 13:22:08

Maybe with Chrome it's slower, but also with Firefox it's not fast. That site can be highly optimized and this can certainly improve its speed.

mck89 2010-07-15 13:25:52

Sure, but the question specifically refers to the performance problems in Chrome and Safari. Also, given that the performance problem only affects this page, it's likely to be something specific to this page.

El Yobo 2010-07-15 13:27:18

I know that the images aren't optimized (I'm not the only who updates the website), but the issues aren't the image loading times.As far as Chrome developer tools, all it will tell me is that "Layout" is taking an extended amount of time to execute.

MetalAdam 2010-07-15 13:57:50

Try to remove the addthis_widget.js script, it loads a lot of resources and it adds an hidden iframe that slows Chrome

mck89 2010-07-15 14:06:28

Looks like removing the addthis widget cut down on half of the delay...

MetalAdam 2010-07-15 14:22:34

Maybe that script is not optimized for Chrome

mck89 2010-07-15 14:32:44

You can try to trace the problem with help of DevTools Timeline.

Timeline video guide

Other DevTools guides

Some changes in Timeline UI happened after recording the video. As example all the top level events are collapsed by default. But the idea is the same.

As I can see it is not a problem with JavaScript but with Layout recalculation.

loislo 2010-07-15 19:25:51

The only information I can gather from this, is that Layout is what is causing the problem. I don't see any ways to get any further information on what exactly is the problem (or at least a ballpark idea).

MetalAdam 2010-07-15 19:30:31

Looks like a bug in renderer. Will try to nail it.

loislo 2010-07-15 19:41:29

at least you can try to find the problem by commenting big sections of the page. If the problem goes away then it is in the excluded part of page. :)

loislo 2010-07-15 20:14:40

looks like you have fixed it. :)

loislo 2010-07-15 20:35:02

ansaurus

tags:

views:

answers:

Slow site... but just in Chrome/Safari

related questions