Monday, July 28, 2008
Starting from AOL pagetest, YSlow, Firebug. Yahoo's performance related pages talk about lot of browser behavior and also tricks to get the best out of it... I think folks should start looking there. And this is only if you are serious about improving your site's performance.
note: Have been out for some time. Lots of work... Now things should get back in track
Sunday, April 27, 2008
- Look for the optimum amount of data to be shown to the user: This is not a technical tip but has to do more with sensitivity to the usage of your site/application. There is a need to get only so much data which the user can see with convenience. For example in our application, we were showing around 25 rows on search results and the vertical scroll bar became pretty big. The side-menu occupied very small part of the browser real-estate. We then changed it to 10 rows and found the page to be more balanced. And that also reduced the amount of data we send across to the browser which increased responsiveness quite a bit. So do look to resize your pages as needed. Don't keep them too big.
- Gzipping/Compressing your response: If you are sending a huge amount of data in your response consider gzipping the content. This reduces the time taken to push the content across to the browser and for internet sites this could do a lot of good to the responsiveness. When doing this keep two things in mind. One: You would be able to use this only if the target browser can handle gzipped content (most browsers do that now a days). Two: Gzipping needs horse (read CPU) power and you better have what is required.
- Sourcing images/static content using hostname aliases: This is more of working around the limitation of the browser. The browser typically cannot make more than two parallel requests for such components with the same hostname. Hence if you create aliases to your host, that will increase the number of parallel requests the browser can make to get these components. Simple! Not so fast. Keep in mind that, this increases the number of DNS lookups and that adds to the overhead. So strike a balance. We plan to have 4 aliases in our application.
- Remove unnecessary inline js and css: It is always a good idea to externalize the inline js and css into linked js and css files. The js and css files are cached by the browser. This reduces the amount of markup sent across in the response each time.
- Use css instead of images for your page styling (like curves): Earlier whenever we wanted different kinds of styling like curves and dots, we used images. Now these can be done by css and rightly so. Using images for these effects will increase the number of requests for painting the page and hence reduce responsiveness. Many js libraries provide plug-ins for these nowadays.
- Fidder/Charles: Both are http debugging proxies. Allows you to analyze request and responses including time, content.
On the whole, we all wish to make our applications very responsive and with least amount of sweat. And these techniques and tools can surely help us.
Friday, April 11, 2008
http://www.bloggingdeveloper.com/post/7-Easy-to-Apply-Tips-to-Improve-Your-Web-Site-Performance.aspx - This one talks about the loading images form multiple domains as one of the points - very interested and something which we are planning to implement
Monday, March 31, 2008
- What jquery claims to be different is the way it uses CSS or Xpath selectors to work with the dom (both html and xml). Comes out pretty short and neat. I really liked that part. made things easy for me in many ways.
- It has support for some ui components like sliders, capability to create curve edges to tables etc. I did not use directly. Other guys in the project have used.
- Also there are a bunch of plug-ins which are quite useful.
Another great concept I got familiar with was closures. I have sort of got a hang of it. but not completely yet.
Mean to try GWT sometime as well.
Thursday, March 6, 2008
1. absence of constructor based dependency injection - The developer has to sacrifice some of the OO flexibility - Use spring instead
2. no provision to pass parameters to the managed bean methods - Developer use various hacks like implementing Map
3. dual call to phaselisteners - this is something which i did not realize - looks more like a bug to me :)
4. huge amount of navigation related xml - this is something we faced - Usage of * can help. This is some trick I probably missed in my project
5. using xml causing runtime exception - this is quite true; may be tools could help - author recommends annotation libraries from Shale and Seam
6. thread safety - some important info in this especially about custom converters and validators. something that should be kept in mind
7. creating component renderer tags with behavior - something to be avoided
8. exposing the entire object hierarchy in el - not sure about this one; done this quite a lot. seems more natural
9. coding to the implementation instead of interface - this is something which we must not do at all
10. not doing view state encryption on client side - good point in terms of security
11. jsf code that is bound to the servlet api - something which i have done a lot I think - this makes it non compatible to portlets - workaround mentioned
That is what is covered. The other issues I faced are already covered in a previous post. Folks who use JSF please keep these in mind
Sunday, February 10, 2008
Some themes which I found interesting were Ruby and RoR, Semantic Web (which I could not attend much even going by my camp standards), Mashups and RIA frameworks. There were standalone sessions on Eclipse Plug-in Development, Android (missed that one) and others. There was one 'any language any website' session which was interesting. Another real good session on 'Product design and development' - really got to know some good concepts. The lightning talks were quite good - the shortness helps mitigating boredom and fostering breadth.
I will probably post later on specific topics I attended here.
Hearing Martin talk was another wish come true.
Overall had a good time and a great experience.
We also discussed on how much the web has moved on… really lots happening out here and we are quite behind the scene…
Then it flashed… we wanted to discuss at any time and the web had the answer…. A wiki has come forth... Iflockt
Starting off with bunch of friends. Let us see what comes up.