Closed
Bug 557562
Opened 14 years ago
Closed 14 years ago
Make Top Landing Pages Faster
Categories
(www.mozilla.org :: General, defect)
www.mozilla.org
General
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bcutler, Assigned: rik)
Details
(Whiteboard: [perf])
Attachments
(2 files, 3 obsolete files)
We would like to improve the page load speed of the Mozilla.com homepage, firefox.html, and ie.html. At minimum, please remove the yui main-nav drop down, remove most (if not all) JS, and inline the CSS. See blog post for more details: http://blog.mozilla.com/metrics/2010/04/05/firefox-page-load-speed-%E2%80%93-part-ii/ Ryan, please chip in if you have something to add. Thanks.
Comment 1•14 years ago
|
||
+1 for trimming everything unnecessary from our landing pages. Notes: * We have a lot of inline JS & tracking scripts that rely on JS, so we need to make sure we don't break something or lose stats. * The JS we can't lose should be moved to the bottom of each page to make the pages load faster * Removing images will help too. Our bg image is about 60k. * Moving other static content to our cdn will help too. http://mozcom-cdn.mozilla.net * If we can, let's post-load the CSS & JS necessary for other pages. Not required, but would be nice.
Comment 2•14 years ago
|
||
(In reply to comment #1) > * If we can, let's post-load the CSS & JS necessary for other pages. Not > required, but would be nice. not really related, let's do that in a separate bug
Comment 3•14 years ago
|
||
I'm going to be on PTO from tomorrow through Sunday, but want to make sure we can get moving on this. Alex, can you take point here? Regarding removing images, I'm not opposed to that necessarily, but let's see how the test we have on removing the background image (bug 556568) goes before we implement that one.
Comment 4•14 years ago
|
||
(In reply to comment #3) > I'm going to be on PTO from tomorrow through Sunday, but want to make sure we > can get moving on this. Alex, can you take point here? Sure
Comment 5•14 years ago
|
||
I'm back now...just checking in. Any progress? Anything I can do to help?
Comment 6•14 years ago
|
||
Hey John No progress so far. I'm working on finding someone who has time to tackle this, will update this afternoon on that.
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 8•14 years ago
|
||
I just got some CSS drop-down menus working (woot!) and dropped a YUI requirement. Still broken in IE 6/7, and needs some general code cleanup, but that should be simple to fix. Attached a patch of the current work in progress.
Comment 9•14 years ago
|
||
We'll have to be careful to ensure that the YUI infrastructure doesn't get dropped from pages that require it for other features. For example, pages with animated tab switching (several of the Firefox landing pages), open/close expanders (release notes). Some of these could potentially be re-written with Jquery, or the YUI assets could be included inline (rather than as separate HTTP requests).
Comment 10•14 years ago
|
||
Just FYI: We already have dropped YUI and rewritten our Japanese page's drop-down menu with CSS and tab switching with jQuery: http://www.mozilla.com/ja/firefox/
Comment 11•14 years ago
|
||
Kohei, looks good. If we do the same for Mozilla.com, there are a few other features in the YUI-based tab-switching that I'd like to preserve. For example, we use anchors to update the URL when the tab is switched so tabs can be bookmarked and browser back/forward buttons can navigate tabs. We also have a few other features, like an alternative default start tab that is used on some pages.
Comment 12•14 years ago
|
||
(In reply to comment #9) > We'll have to be careful to ensure that the YUI infrastructure doesn't get > dropped from pages that require it for other features. For example, pages with > animated tab switching (several of the Firefox landing pages), open/close > expanders (release notes). I'm hoping to drop YUI completely soon, but yes, in the meantime I'll be careful not to break other things > Some of these could potentially be re-written with Jquery, or the YUI assets > could be included inline (rather than as separate HTTP requests). jquery++ (In reply to comment #10) > Just FYI: We already have dropped YUI and rewritten our Japanese page's > drop-down menu with CSS and tab switching with jQuery: > http://www.mozilla.com/ja/firefox/ I'm really sad that our mozilla.com sites are separate and we don't share this kind of change automatically. That would have saved me a few hours.
Comment 13•14 years ago
|
||
update: fixes drop downs for ie 6/7 still need: * code clean up * mouse hover event delay. i.e. the YUI code introduces a small delay when a mouse hovers over a nav menu, while the current css menu patch has no delay, and the menus drop immediately when the mouse passes over the menu.
Attachment #441993 -
Attachment is obsolete: true
Comment 14•14 years ago
|
||
Attachment #442168 -
Attachment is obsolete: true
Comment 15•14 years ago
|
||
Hey Alex, Since I plan to be using your CSS/JS for SUMO, I'm up for reviewing this and sharing whatever improvements I'm making on our end. What's a URL where I can see this? Somewhere on Khan maybe?
Comment 16•14 years ago
|
||
Might be worth getting this running in a browseable branch for some testing/improvements.
Comment 17•14 years ago
|
||
(In reply to comment #12) > I'm really sad that our mozilla.com sites are separate and we don't share this > kind of change automatically. That would have saved me a few hours. As Mozilla Japan is an affiliate of the Mozilla Foundation, we have run separate sites/servers, tried to improve contents/performance for Japanese users, and done some experimental stuff. Unfortunately, because of lack of human resources, it's difficult to watch every MoCo WebDev efforts and give feedback, but I think we can do better.
Reporter | ||
Comment 18•14 years ago
|
||
where do we stand on this bug?
Comment 19•14 years ago
|
||
(In reply to comment #18) > where do we stand on this bug? Currently, I've cut out about 10 HTTP connections and moved most Javascript to the foot of the page. This has cut about 0.7-1.0 seconds off total page load time, although I'm not sure yet how *perceived* load time is affected (i.e. how fast the user sees the download button, or feels that page is loaded, or just sees *something*) I hope to have a test page up this week, to show the current progress. There's still lots to do, including dropping the YUI menu, inlining JS / CSS, and possibly making an image sprite for the header.
Reporter | ||
Comment 20•14 years ago
|
||
Can I get an ETA? This is blocking some new tests we'd like run.
Comment 21•14 years ago
|
||
(In reply to comment #20) > Can I get an ETA? This is blocking some new tests we'd like run. I can't give a reliable estimate right now. I have other projects taking priority, and last I worked on this, I remember there was lots of work to do. Could you explain how this is blocking your new tests?
Reporter | ||
Comment 22•14 years ago
|
||
Any further changes we make will be heavily biased by the speed difference. I don't want to push this too hard, but waiting is costing us over 200k Firefox downloads a week. Seems like this should be given higher priority.
Comment 23•14 years ago
|
||
(In reply to comment #22) > Any further changes we make will be heavily biased by the speed difference. Could you give an example? I don't understand. Are the new tests based on a page that is considerably faster than the base page being tested? > I don't want to push this too hard, but waiting is costing us over 200k Firefox > downloads a week. Seems like this should be given higher priority. I agree, I'd like to see this move also. You need to work with Morgamic to make sure this has the right priority please.
Reporter | ||
Comment 24•14 years ago
|
||
New tests should use previous winning variations as the control. If we don't do this, results from experiments on unoptimized pages won't necessarily apply to optimized pages.
Comment 25•14 years ago
|
||
Wonder if Wilson can help out with this one? If we can catalog what is left to do maybe we can get some extra help with it.
Reporter | ||
Comment 26•14 years ago
|
||
Any updates here?
Comment 27•14 years ago
|
||
worked on this a bunch today. r70339 adds speed improvements to en-US/index.html This took off 0.5 seconds from the time until the first page element is seen. Also, took off 1 second from the time until the download button is seen. (tests run on www-trunk.stage with webpagetest.org)
Comment 28•14 years ago
|
||
Comment 29•14 years ago
|
||
Updated•14 years ago
|
Attachment #442301 -
Attachment is obsolete: true
Comment 30•14 years ago
|
||
TODO * fix header nav drop down hover delay ( I broke it when removing YUI ) * try inlining CSS/JS * apply to en-US/firefox/[personal, upgrade, firefox] Note (mostly to Steven G.) that postponing the JS code that loads the heavy (60Kb+) background image until the footer of the page makes a huge difference. We could easily make this change on a lot of our pages, and in the future site redesign. Probably useful for font files too.
Comment 31•14 years ago
|
||
Hooray!
Comment 32•14 years ago
|
||
Time for an update... Inlined CSS/JS, this is on stage for en-US/index.html. It took off ~0.2 seconds. Applied these updates to other pages, including firefox/[ie, upgrade, firefox, personal] That caused an issue with the video player JS, so working on fixing that before I commit to trunk. I'm also working on getting rid of the old-style, mid-page JS for building download buttons, because it blocks page load (and because it's old and ugly). That's bug 578817. An example is on stage at www-trunk.stage.mozilla.com/test.html and a comparison is here http://www.webpagetest.org/video/compare.php?tests=100714_1CCZ%2C100714_1CD0&thumbSize=200&ival=100 (notice the first page elements are actually loaded later, weird, but the download link shows up a lot sooner)
Comment 33•14 years ago
|
||
An idea for moar speed: Often a lot of time is wasted with redirects. For example, when someone goes to "firefox.com", the waterfall looks like this, http://www.webpagetest.org/result/100715_1E41/1/details/ Nearly half the time is spent on redirects. There may be a couple options for cutting this down 1) can we use a CNAME for firefox.com, instead of a 302? I'll admit, I'm uneducated on CNAMEs and DNS, so maybe that doesn't make sense. 2) pages like /firefox/[firefox,ie,upgrade] are always reached via a redirect (dependent on which browser the user is using) can we figure out how to show different page content without redirecting (and how does that play with Zeus)? Is it still worth it to have separate pages per user agent? Which is more effective, a fast page without redirects, or a slower page with very minor content changes? We should look at this approach and assess whether it still makes sense. For reference, I'm speaking of these, http://www.mozilla.com/en-US/firefox/upgrade http://www.mozilla.com/en-US/firefox/ie http://www.mozilla.com/en-US/firefox/firefox.html
Reporter | ||
Comment 34•14 years ago
|
||
That's an interesting question Alex. I'd guess a slow page with minor content changes is better. It's likely something we can test, though.
Comment 35•14 years ago
|
||
(In reply to comment #34) > That's an interesting question Alex. I'd guess a slow page with minor content > changes is better. It's likely something we can test, though. The content changes are so subtle, and the results from performance tests have been so huge, that I was thinking the opposite. I'd like to get together soon and design a test (or series of tests) so we can prove it one way or the other.
Comment 36•14 years ago
|
||
Really interesting thoughts in comment #33, Alex. We should discuss further offline, b/c you touch on some things that go beyond the scope of just this bug. But, for the sake of starting the conversation: - as you know, we're talking about renaming the site from mozilla.com anyway...we should consider the redirect/speed issue when we decide which direction to go in. If we do that right, it might solve a lot of these problems in a pretty straightforward way. - with regard to separate pages per user agent, the plan for the redesigned site is to have a landing page for users of the latest Firefox and a landing page for everyone else. I think it's really important to segment between those groups (because the calls to action are so different), but beyond that I don't think we gain all that much by slicing it up browser by browser. We should continue to test that once the new site is up, though.
Comment 37•14 years ago
|
||
(In reply to comment #36) > But, for the sake of starting the conversation: > - as you know, we're talking about renaming the site from mozilla.com Good point, I won't worry about firefox.com for now, but it's important to keep in mind when we start implementing redirects from other URLs to the final choice. BTW, is that happening with the redesign? Before? After? How are we deciding? I haven't heard much on that topic for awhile. > - with regard to separate pages per user agent, the plan for the redesigned > site is to have a landing page for users of the latest Firefox and a landing > page for everyone else. I think it's really important to segment between those > groups (because the calls to action are so different), but beyond that I don't > think we gain all that much by slicing it up browser by browser. We should > continue to test that once the new site is up, though. Sounds great, I like that distinction a lot, and it sounds like the content will be much more varied than it is now. With the redesign around the corner, it doesn't really make sense to test pages that will be going away very soon. There is still a technical question of how to show different content to different browsers without a redirect. I have an idea for that, I'll write it down soon. Thanks for the feedback.
Reporter | ||
Comment 38•14 years ago
|
||
Hey Alex, have any performance improvements been pushed yet?
Comment 39•14 years ago
|
||
(In reply to comment #38) > Hey Alex, have any performance improvements been pushed yet? No, I can work on pushing what I have done this week though.
Comment 40•14 years ago
|
||
(In reply to comment #10) > Just FYI: We already have dropped YUI and rewritten our Japanese page's > drop-down menu with CSS and tab switching with jQuery: > http://www.mozilla.com/ja/firefox/ I have updated the dropdown menu to support WAI-ARIA. It's built with jQuery but still works without JavaScript.
Comment 41•14 years ago
|
||
The tab switching has also been updated to support WAI-ARIA using role="tablist", "tab", "tabpanel", etc. See Bug 519325 for implementing those ARIA roles.
Reporter | ||
Comment 42•14 years ago
|
||
Any updates here? Here's a video that visualizes our page load speed today: http://www.webpagetest.org/video/view.php?id=100929_42cc561061e730e82bcc9688098f348b48f861bd Our conversion rate is 12.5% lower than it should be. Please let me know what I can do to move this along.
Updated•14 years ago
|
Whiteboard: [speed]
Updated•14 years ago
|
Whiteboard: [speed] → [perf]
Comment 44•14 years ago
|
||
(In reply to comment #43) > Alex is this a dupe? A dupe of bug 589315? Ya, it the same purpose/work to do/assignee, but it's focused on firstrun/whatsnew pages.
Assignee | ||
Comment 45•14 years ago
|
||
Marking this as fixed since the new design has been released and improvements were done on them.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 46•14 years ago
|
||
(In reply to comment #45) > Marking this as fixed since the new design has been released and improvements > were done on them. verified fixed
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Component: www.mozilla.org/firefox → www.mozilla.org
Updated•12 years ago
|
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•