FireBug / Page Speed

I've been playing around using FireBug / Page Speed on some of my Clients' Test and Prod Elgg sites. I see some interesting comments from running the analyses and the various recommendations. Has anyone else used FB/PS to good effect ? I'd be curious to exchange notes here. e.g. simple recommendations such as "Minifying the following CSS resources could reduce their size by 16.3KiB (17% reduction)" and "Optimizing the following images could reduce their size by 13.1KiB (32% reduction). " is staggering and reminds us how stewpid we sometimes get to be with unoptimized code... 2 am++ goodnight - I'll be back tomorrow...

I've been playing around using FireBug / Page Speed on some of my Clients' Test and Prod Elgg sites. I se some interesting comments from running the analyses and the various recommendations. Has anyone else used FB/PS to good effect ? I'd be curious to exchange notes here. e.g. simple recommendations such as "Minifying the following CSS resources could reduce their size by 16.3KiB (17% reduction)" and "Optimizing the following images could reduce their size by 13.1KiB (32% reduction). " is staggering and reminds us how stewpid we sometimes get to be with unoptimized code... 2:30 am++ goodnight - I'll be back tomorrow...

 

  • My Site has 33 plugins actived with only 1 js file and 1 css but i'm still soffering response from database

    YSlow Grade:
    (86%)

    Page Speed Grade:
    (93%)

    Page load time: 3.15s
    Total page size: 80.9KB
    Total number of requests: 13

  • @lord55 How can you combine all javascripts , any idea please because I already tried this before but it disable my site's functionality.

  • THE POINT on dashboard on my server when I loggin in Elgg with this amount of plugin (because Page load time: 3.15s is only for index page with very minimalist page):

    • Time to First Impression/Drawing on Dashboard: 13.09s
      • Analysis: so it takes almost 13s until the user sees a visual indication of the page load – that is definitely too long and should be improved
      • Recommendation: < 1s is great. <2.5s is acceptable
    • Time to onLoad: 13.45s
      • Analysis: it takes the browser 14s to download the initial document plus all referenced objects before it triggers the onLoad event that allows JavaScript to modify the page after it has been loaded – again – much too slow as nobody likes to wait 14s until the content is loaded
      • Recommendation: < 2s is great. <4s is acceptable
    • Time to Fully Loaded: 14.12s
      • the page loads additional resources triggered by JavaScript onLoad handlers. I consider the page as fully loaded when all these additional requests are downloaded. I guess I don’t need to mention that 14s is not fast 
      • Recommendations: < 2s is great. <5s is acceptable
    • Number of HTTP Requests: 25
      • Analysis: consider that there is only one call to all js and one for all css and images (all images are called with one request in the css)
      • Recommendations: < 20 is great. < 100 is acceptable (This one is a hard recommendation as it really depends on the type of website – but – it is a good start to measure this KPI)
    • Number and Impact of HTTP Redirects: 0s
      • Analysis:
      • Recommendations: 0. Avoid Redirects whenever possible
    • Number and Impact of HTTP 400’s: 0s
      • Analysis:
      • Recommendations: 0. Avoid any 400’s and 500’s
    • Size of JavaScript/CSS and Images: ~40kb/18kb in deflate mode
      • Analysis:they are very small but I still have 3s for a minimalist index page
      • Recommendations: It is better to load what needs to be loaded in the beginning and delay load additional content when really needed
  • combine.php & the rewrite will need to also cater for the elgg  js.php css.php and however many plugins extend the css and the js - some messy clerical typing.

    elgg is somewhat db heavy(ier) than the average cms's like wp, joom, etc - database performance tweaking will be an ongoing process, not something that can be cured by a few simple tweaks. i've been 'tweaking' the mysql server for fbfkids.com for the past 12 months and do not see the task come to any end soon. apache performance on the other hand is yet another headache - all those 10 million parms ;-)

    i'll try to find spare time to study the combine.php stuff in more to see if that can be used to improve elgg's load speeds, but this will take some time to experiment - don't hold your breath..

  • hmmm... just checked fk, logged out, logged in, moved from page to page here and there - seems quite steady at about 2 - 4 secs per page. i think people should also look at the kind of server the site is running on, ram, etc - because these aspects will have an affect of speeds.one of the small things we did last year was to disable the elgg log completely since that was becoming hugh and taking up too much heat on apache/mysql. today we have no logs at all. we do compare the beast fk with our smaller fbf sites fbfteens @ 10K, fbfkiddies @ 5k (yes we have these too;) to try and get some perspective on how and why the different sized sites perform (on the same server)

  • @Dhrup are you using Memcache or squid cache on fbfkids and how many pluggins installed.

    I personally feels that group plugin is much havier that other plugins.

  • ( I'm not certain that all my answers will really help ohers streamline their speeds because of server/ power/ system load differences) we have abt 23 plugins (and wouldn't y'all like to get your hands on some of those? ), no memcache, no squid. we had planned to install apc (and or turck) some months back but got sidetracked and now - lack of programming resources since the mastermind has left us ;-( we've been thinking abt checking out ec-cloud but who's got the time for the research ? i personally not feel the groups plugin is "heavy" - one has to look at how the code in a plugin gets loaded and what other code is pulled in by the start.php for each page load - that affects the speed.

  • as @Dhrup said the first thing is the host. many of us use an hosting service and the first thing to know is that you have what you paid. so the first thing is to see for a good host with good quality.

     

  • Thanks Dhrup one thing more is eAccelerator works same like memcache or memcache is better.

    If both are enabled then any conflict in these two and what about APC is that a better then memcache , I am totally confused in between these cache. On my dedicated server eAccelerator and memcache both are installed but unfortunately memcache is not working I think I did not unblock port 11211 port from firewall.

    I a get same result as you said 2 sec for every page from remote location but on local about 0.215 for dashboard and 0.614 for profile . I have only 100 users . and Internet speed is 20Mbps downloading , 5Mbps uploading .

    any suggestions


  • I found some interesting results here and want to share with community:-

    The results are summarized in this table. Attached to this article you can find a spreadsheet (ODS format) with the raw data and calculations.

      PHP with APC % over PHP with eAccelerator % over PHP eA vs. APC
    Drupal 5            
    Total seconds 183.49 37.16 493.85% 32.64 562.16% 113.83%
    Requests/second 4.45 26.91 604.72% 30.64 688.54% 113.86%
    millisecs per request 183.49 37.16 493.86% 32.64 562.15% 113.83%
                 
    HEAD            
    Total seconds 175.62 33.21 528.83% 29.18 601.85% 113.81%
    Requests/second 5.69 30.11 529.17% 34.26 602.11% 113.78%
    millisecs per request 175.62 33.21 528.83% 29.19 601.71% 113.78%

    Conclusion

    On the test setup, both APC and eAccelerator show marked improvement over plain PHP. eAccelerator consistently faster by 13% over APC.

    Other tests, not included in this benchmark, show that eAccelerator saves about 5MB per Apache process over APC, so there are other benefits.