Would this make Smugmug faster?
jfriend
Registered Users Posts: 8,097 Major grins
While looking at some caching related things for this thread, I noticed that my home page includes a bunch of different style sheets and javascript files and, of course refers to a lot of images. For style sheets, it includes:
http://css.smugmug.com/include/css/smugmugBlack-20070621223257.css
http://css.smugmug.com/include/css/user_jfriend-20070614190131.css
http://jfriend.smugmug.com/include/css/yui_core.css
http://jfriend.smugmug.com/include/js/yui/fonts/fonts.css
http://jfriend.smugmug.com/include/js/yui/container/assets/container.css
http://jfriend.smugmug.com/include/js/yui/tabview/assets/tabview.css
http://jfriend.smugmug.com/include/js/yui/menu/assets/menu.css
http://css.smugmug.com/include/css/user_jfriend-20070614190131.css
Since all of these except for the user_jfriend style sheet are common to all Smugmug users, I'm wondering why four of these are referenced from the jfriend.smugmug.com domain instead of css.smugmug.com. It seems that if they were referenced off of css.smugmug.com that the browser could much more efficiently cache these files for all smugmug sites that a given user visits rather than caching them separately for each Smugmug site that is visited.
Wouldn't this save Smugmug download bandwidth and speed up the initial loading of second, third and fourth sites that one visits?
The Javascript includes are mostly coming from js.smugmug.com, but there are still some that are not:
http://jfriend.smugmug.com/include/js/homepage_ajax-20070427070019.js
Also, for some of the standard images used in the UI, some are also on the jfriend domain that could more effectively be cached on a standard smugmug.com domain. While these images aren't big, it would save networking round-trips to let them be cached more effectively:
http://jfriend.smugmug.com/img/spacer.gif
http://jfriend.smugmug.com/img/throbberBlack.gif
http://css.smugmug.com/include/css/smugmugBlack-20070621223257.css
http://css.smugmug.com/include/css/user_jfriend-20070614190131.css
http://jfriend.smugmug.com/include/css/yui_core.css
http://jfriend.smugmug.com/include/js/yui/fonts/fonts.css
http://jfriend.smugmug.com/include/js/yui/container/assets/container.css
http://jfriend.smugmug.com/include/js/yui/tabview/assets/tabview.css
http://jfriend.smugmug.com/include/js/yui/menu/assets/menu.css
http://css.smugmug.com/include/css/user_jfriend-20070614190131.css
Since all of these except for the user_jfriend style sheet are common to all Smugmug users, I'm wondering why four of these are referenced from the jfriend.smugmug.com domain instead of css.smugmug.com. It seems that if they were referenced off of css.smugmug.com that the browser could much more efficiently cache these files for all smugmug sites that a given user visits rather than caching them separately for each Smugmug site that is visited.
Wouldn't this save Smugmug download bandwidth and speed up the initial loading of second, third and fourth sites that one visits?
The Javascript includes are mostly coming from js.smugmug.com, but there are still some that are not:
http://jfriend.smugmug.com/include/js/homepage_ajax-20070427070019.js
Also, for some of the standard images used in the UI, some are also on the jfriend domain that could more effectively be cached on a standard smugmug.com domain. While these images aren't big, it would save networking round-trips to let them be cached more effectively:
http://jfriend.smugmug.com/img/spacer.gif
http://jfriend.smugmug.com/img/throbberBlack.gif
--John
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
0
Comments
Portfolio • Workshops • Facebook • Twitter
the homepage_ajax javascript file has to be hosted from your domain because it contains google maps code and needs to match the domain you registered with google.
we are thinking through a few different ways of handling the standard UI images.