Closed Bug 557562 Opened 14 years ago Closed 14 years ago

Make Top Landing Pages Faster

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bcutler, Assigned: rik)

Details

(Whiteboard: [perf])

Attachments

(2 files, 3 obsolete files)

filmstrip test on stage before the changes
116.03 KB, image/png
Details
filmstrip test on stage after the changes
122.62 KB, image/png
Details 
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.
+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.
(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
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.
(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
I'm back now...just checking in. Any progress? Anything I can do to help?
Hey John

No progress so far.  I'm working on finding someone who has time to tackle this, will update this afternoon on that.
OS: Mac OS X → All
Hardware: x86 → All
Made some room, I'll work on it this week
Assignee: nobody → buchanae
Attached patch Drop YUI menu, broken in IE 6/7 (obsolete) — — Splinter Review 
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.
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).
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/
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.
(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.
Attached patch Drop YUI menu, fixed for ie 6/7 (obsolete) — — Splinter Review 
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
Attached patch drop yui menu (obsolete) — — Splinter Review 

        Attachment #442168 -
        Attachment is obsolete: true

    
    

    
  
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?

    
    

    
  
Might be worth getting this running in a browseable branch for some testing/improvements.

    
    

    
  
(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.

    
    

    
  
where do we stand on this bug?

    
    

    
  
(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.

    
    

    
  
Can I get an ETA?  This is blocking some new tests we'd like run.

    
    

    
  
(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?

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
Any updates here?

    
    

    
  
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)

        Attachment #442301 -
        Attachment is obsolete: true

    
    

    
  
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.

    
    

    
  
Hooray!

    
    

    
  
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)

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
Hey Alex, have any performance improvements been pushed yet?

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
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.
Whiteboard: [speed]
Whiteboard: [speed] → [perf]

    
    

    
  
Alex is this a dupe?
Assignee: abuchanan → anthony

    
    

    
  
(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.

    
    

    
  
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

    
    

    
  
(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
Component: www.mozilla.org/firefox → www.mozilla.org
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: