i don't find it slow so it seems good from my side :)
CatALiNa6, Aug 24, 2009 @ 14:52

Still slow here, & I can NOT reply to any mails in my inbox... Thanks for all the work you are doing, and sorry for not replying to anyone. :-)))
SWISS, Aug 24, 2009 @ 15:06

Hi Swiss

What happens when you try to reply to a mail in your inbox?

Thanks

Oded

SiteAdmin Oded, Aug 24, 2009 @ 15:17

 Very slow...

kayili, Aug 24, 2009 @ 15:28

 It just takes time to set up so that you can actually reply... otherwise, things seem to be going well in terms of speed - at least for me... :o)  J.
JulianT, Aug 24, 2009 @ 19:35

Thanks guys.

Anyone else?

Is the site still slow?

Oded

SiteAdmin Oded, Aug 24, 2009 @ 22:15

 Hi!

Sometimes it is fast and when you try to change tabs it just stalls and takes for ever to load the page and even times out!
vkheinrich, Aug 25, 2009 @ 08:43

 I think the site is a bit faster, compared to ten days ago or so (when I first started using it again).


rainer_d, Aug 25, 2009 @ 12:30

 Is it just me or does the back button not work anymore? 

Jules
JulieAnn, Aug 25, 2009 @ 13:05

Thanks Rainer

So its faster than it was but still slow?

Oded

SiteAdmin Oded, Aug 25, 2009 @ 13:16

Thanks Jonathan.

We will definitely keep working on the speed, cause if the site is slow, it's not fun to use.

Seems we have times when everything is fast, and times when nothing moves.

We're trying to understand what's causing this and to fix it, so please keep the feedback coming and let us know if certain pages are especialy slow.

Thanks

Oded

SiteAdmin Oded, Aug 25, 2009 @ 13:52

 To get to this forum, it was not slow, but when I posted an event it was slow, and when I tried to invite friends, it never managed that!
Best, Jane

Ginger, Aug 25, 2009 @ 14:25

Its still too slow for me. I don't think the new website hits are anywhere near as much as it used to be.  Good work, but more needs to be done. keep going. thanks.

popeye, Aug 25, 2009 @ 15:48

I doubt the site is slow because of code (the only thing you could do non hardware-wise is to improve your server caching methods) . I think its slow because of the bandwidth constraints that ISPs place on multiple connections from the same source. (nb: it was slow even before the migration). You could alleviate this problem (but not solve it) by introducing a load balancer or even better, move your server from Israel to a datacenter in Switzerland - then you would notice an earth-shatteringly dumbfounding improvement. Alternatively, you could invest a few million Swiss francs on a fibre optic dedicated line.

facemelter, Aug 25, 2009 @ 17:02

 Facemelter:

Thanks. Most experts we spoke with told us the server's physical location would make very little speed difference. You're not in the same opinion?

Nir


Nir Ofek, Aug 25, 2009 @ 17:12

The new site looks great!  It works the same for me as it did before.  I don't notice it being slow.
Thanks for Glocals.com... period!

Branta C, Aug 25, 2009 @ 20:40

There are some excellent free tools to help you find the cause of 'slow' web pages. I've used these tools and run them on the glocals front page. See the attached images for the results. These tools seem to agree on the fact that significant performance improvements are possible. And you don't (necessarily) need to move the site from Israel to Switzerland.

If you want to run these tools for yourself, then first install the Firebug addon for Firefox, and then add Yahoo's YSlow plugin and Google's Page Speed plugin. They give you concrete advise on which changes you need to make to improve performance.

Also, I would really recommend scaling the member pictures to the size that's in use on the web page. For example, on the front page a (relatively) huge 500x336 picture is loaded, but it is displayed at only 36x36 pixels. This means far too much data is transferred, which slows down the web page. Fixing this not only improves performance, but it will also save you bandwidth - and money. You could easily write a script to do this 'on the fly', i.e. dynamically, and then cache the results. Instead of doing 'img src="memberpicture.jpg"' you write 'img src="scale.php?file=memberpicture.jpg&w=36&h=36'". Also, make sure you cache the results! If you scaled an image to a certain size, save it somewhere in a special 'cache' directory. If you don't do this, your server will probably crash under the load :)

Anyway, hope this helps. In case you're wondering - yes, this is what I do for a living. I'm an independent Internet consultant, and you can hire me if you need a website, have a website problem or if you have a complex internet project no-one else will touch. See my website here: infostreams.net/consultancy

thedutchguy, Aug 28, 2009 @ 15:58

 theDutchGuy, Bedrock,

Big thanks for the concrete advice, we appreciate it very much that you took the time to share your expertise with us. We shared the feedback with our tech guys for their feedback (as the tech skills of both me and SiteAdmin are not strong enough for this), and will revert asap.

Thanks again, we're grateful for your advice,

Nir

Nir Ofek, Aug 29, 2009 @ 15:02

Hi guys and thanks for the feedback.

For the first couple of weeks, the site was extremely slow, and the main culprits were several 'heavy' sql calls, and several 'heavy' sql tables, so we focused our efforts on the big problems.

Now that the sql querries are relatively optimized and the site is moving at a decent speed, we will move on to optimizing and improving the html, css and page weight.

Your feedback will help us to focus our efforts, so thanks again, and please keep it coming.

Oded

SiteAdmin Oded, Aug 29, 2009 @ 15:59

No problem :) Using these tools could really improve performance I think. According to Yahoo, 80% of the end-user response time is spent on the front-end - so forget about proxies, distributed servers and just focus on this :) If you have any problems implementing these changes, please contact me; I might be able to help.

thedutchguy, Aug 29, 2009 @ 16:04

totally agree with Facemelter, for me it's same as before, because we had the same
problem..but I should say that it's not too slow, still okay to surf. it could be much faster if
you find a sever in Switzerland, also it depends on the internet connection speed
too, btw one more question, is online chat coming soon ( just
curious), rgdsJohn
ja_nixon, Aug 30, 2009 @ 21:48

For fun, I ran an analysis on a friend's website and it came up without any issues. Here are the results for Glocals that support's theDutchGuy's review (thanks for the education on website optimization). Some good opportunities to lighten things up which will help the speed for sure.

This is the website I used: http://analyze.websiteoptimization.com/wso
Analysis and Recommendations (glocals.com)

TOTAL_HTML - Congratulations, the total number of HTML files on this page
(including the main HTML file) is 1 which most browsers can
multithread. Minimizing HTTP requests is key for web site
optimization. Y TOTAL_OBJECTS - Warning!
The total number of objects on this page is 331 which by their number
will dominate web page delay. Consider reducing this to a more
reasonable number. Above 20 objects per page the overhead from dealing
with the actual objects (description time and wait time) accounts for
more than 80% of whole page latency. See Figure II-3: Relative distribution of latency components showing that object overhead dominates web page latency in Website Optimization Secrets for more details on how object overhead dominates web page latency. Combine, refine, and optimize your external
objects. Replace graphic rollovers with CSS rollovers to speed
display and minimize HTTP requests. Consider using CSS sprites
to help consolidate decorative images. Using CSS techniques such as
colored backgrounds, borders, or spacing instead of graphic techniques
can reduce HTTP requests. Replace graphic text headers with CSS text
headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames or a CDN to reduce object overhead. TOTAL_IMAGES - Warning! The total number of images on this page
is 308 , consider reducing this to a more reasonable
number. Recommend combining, replacing, and optimizing your graphics. Replace graphic
rollover menus with CSS rollover menus to speed display and minimize HTTP requests. Consider using CSS sprites
to help consolidate decorative images. Use CSS techniques such as
colored backgrounds, borders, or spacing instead of graphic techniques
to reduce HTTP requests. Replace graphic text headers with CSS text
headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames to reduce object overhead. TOTAL_CSS - Caution.
The total number of external CSS files on this page is 5 , consider
reducing this to a more reasonable number. Because external CSS files
must be in the HEAD of your HTML document, they must load first before
any BODY content displays. Although they are cached upon subsequent
requests, CSS files slow down the initial display of your page.
Combine, refine, and optimize your external CSS files. Ideally you
should have one (or even embed CSS for high-traffic pages) on your
pages. You can optimize CSS files using shorthand properties, grouping, and then minify and GZIP compress them to reduce their footprint.
Remember to place CSS files in the HEAD and JavaScript files at the end of the BODY to enable progressive display. TOTAL_SIZE - Warning! The total size of this page is
2579109 bytes, which will load in 580.21 seconds
on a 56Kbps modem. Consider reducing total page size to less than
100K to achieve sub 20 second response times on 56K connections.
Pages over 100K exceed most attention thresholds at 56Kbps, even with
feedback. Consider optimizing your site with Website Optimization Secrets, Speed Up Your Site or
contacting us about our
optimization services. TOTAL_SCRIPT - Warning! The total number of external script
files on this page is 17 , consider reducing this to a
more reasonable number.

Combine, refactor, and minify to optimize your JavaScript files.
Ideally you should have one (or even embed scripts for high-traffic
pages) on your pages. Consider suturing JavaScript files together
at the server to minimize HTTP requests. Placing external JavaScript
files at the bottom of your BODY, and CSS files in the HEAD enables
progressive display in XHTML web pages. HTML_SIZE - Caution. The total size of this HTML file is
51937 bytes, which is above 50K but below 100K. With 50K of images and multimedia
this means that your page will load in about 20 seconds.
Consider optimizing your HTML and eliminating unnecessary features.
To give your users feedback, consider layering your page or using
positioning to display useful content within the first two seconds. IMAGES_SIZE - Warning! The total size of your images is
1569265 bytes, which is over 100K. Consider switch graphic formats
to achive smaller file sizes (from JPEG to PNG for example). Finally,
substitute CSS techniques for graphics techniques to create colored
borders, backgrounds, and spacing. SCRIPT_SIZE - Warning! The total size of external your scripts is
734020 bytes, which is over 20K. Consider optimizing your JavaScript for size, combining them, and using HTTP compression where
appropriate for any scripts placed in the HEAD of your documents. You can substitute CSS menus for JavaScript-based menus to minimize or even eliminate the use of JavaScript. CSS_SIZE - Warning! The total size of your external CSS is
223887 bytes, which is over 20K. Consider optimizing your CSS
for size by eliminating whitespace, using shorthand notation, and
combining multiple CSS files where appropriate. By using labeled
container cells and descendant selectors you can target chunks of HTML content efficiently without the need to embed extra classes and styles. MULTIM_SIZE - Congratulations, the total size of all your
external multimedia files is 0 bytes, which is less than
10K.
Verbier, Aug 31, 2009 @ 10:29

I looked at the site recommeded by Verbier, and to be honest, I was quite shocked by the results. Here's the relevant parts:

Total HTTP Requests: 331
Total Size: 2574416 bytes
Total CSS Images:275

331 HTTP requests?!? That's outrageous! Granted, this is probably only true the first time someone visits the site (those images are in the cache afterwards), but it's likely that performance could be improved significantly if you could reduce that number to something more modest - say, 20 or 30.

To quote Yahoo (again): Our experience shows that reducing the number of HTTP requests
has the biggest impact on reducing response time and is often the
easiest performance improvement to make.

To do this, I would highly recommend implementing a technique called CSS sprites. Read more about it on this page.

The reason why I think this will work is that at the moment, there are 275 HTTP requests that each request some (very) small image, like the bottom-right corner of a box or the right hand side of a tab. These images are smaller than 1 kB on average. If you combine all these images into one large image, this will accomplish two things:

1. The page loads faster - each HTTP request takes time, and the user has to wait for this. Plus, the user's browser can typically only process 4 to 10 requests at a time, so these requests are queued, so it takes even more time to load the page.

2. The load on your server decreases, because it has to handle fewer requests. Instead of handing 331 requests per web page, it only has to handle something like 30. This will decrease the load on your server, so it will handle other requests more quickly, which will improve overall performance.

So this is a win-win situation really. And it's a simple thing to implement; implementing it would probably not take more than a day. You can use automated tools like this to convert those 275+ images into 1; it even generates the associated CSS code for you. I've used it before and it's not perfect, but it's a good start.

Hope this helps,
Edward

thedutchguy, Aug 31, 2009 @ 11:59