Optimize IE.html Page Load Speed

VERIFIED WONTFIX

Status

www.mozilla.org
General
VERIFIED WONTFIX
8 years ago
5 years ago

People

(Reporter: Blake Cutler, Assigned: sgarrity)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [perf], URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
We have discovered that a 1 sec increase in page load speed decreases download conversions by ~2.7%.  Here's a video comparing how our download page stacks up against Chrome and Opera: http://www.youtube.com/watch?v=9mWDlCVRSrY.

I'd like to test an optimized version of IE.html that uses no JavaScript and no external style sheets. I would also like to sprite the images (where applicable), remove the main-nav drop down, and replace the footer with a shortened version:

<p id="footer-links"><a href="/en-US/privacy-policy.html">Privacy Policy</a> &nbsp;|&nbsp; 
<a href="/en-US/about/legal.html">Legal Notices</a> &nbsp;|&nbsp;
<a href="/en-US/legal/fraud-report/index.html">Report Trademark Abuse</a>
</p> 

Only IE users will be assigned to our test, so we do not need to use JavaScript to alter the download button copy.  Ryan, please chime in if I've misstated something.  Thanks!
Are we A/B-testing, or just replacing the page for now? (That's reversible of course).
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Comment 2

8 years ago
It's an A/B run through SiteSpect.  We won't make any changes to the mozilla.com code.
Okay -- where do we put the pictures then? Do you want me to hand you a self-contained zip file?

I'll work on this Monday.
(Reporter)

Comment 4

8 years ago
Please push them to production under this directory: http://www.mozilla.com/img/ss/
I embedded the CSS, removed unnecessary rules, and made the changes mentioned above. Here is the code: https://gist.github.com/d0183454bf0eef3a19bb
Should I put that on mozilla.com, or how does that work?

I didn't do any additional spriting at the moment, because the image count is relatively low. Including the favicon, we are now loading 10 external resources on this page.

Side note: For a long-term solution, we have two options. Either we keep our landing pages as lean as possible, at the cost of special-casing them and removing things like the footer, JS, etc., or we'll need to make mozilla.com more performant as a whole. There are a handful of things that can be done (like minifying all JS and CSS, which we only partly do at the moment), not using YUI *and* jQuery, and so on. But that probably needs to be part of a more general "realign mozilla.com" project that'll have to deal with a bunch of legacy resources as well.
(Reporter)

Comment 6

8 years ago
Looks great!  I should have mentioned this earlier, but could you add the Products, Add-ons, Support, Community, and About main-nav links (without the YUI dropdown)?
Very excited to see the results of this test.  A few notes...

I see you've removed all Javascript.  The download button on this new page will not correctly detect the user's operating system and language without Javascript.  It could be embedded in the page, for testing performance of fewer HTTP connections.

(In reply to comment #5)
> I embedded the CSS, removed unnecessary rules, and made the changes mentioned
> above. Here is the code: https://gist.github.com/d0183454bf0eef3a19bb
> Should I put that on mozilla.com, or how does that work?
> 

Afaik, yes, most tests are checked into SVN.  e.g.
http://svn.mozilla.org/projects/mozilla.com/trunk/en-US/firefox/3.6/firstrun/a/
(notice the /a/ meaning it's version A of a multivariate test)

> I didn't do any additional spriting at the moment, because the image count is
> relatively low. Including the favicon, we are now loading 10 external resources
> on this page.
> 

In order to make this page as lean as possible, should we try to cut out as many images as possible?

> Side note: For a long-term solution, we have two options. Either we keep our
> landing pages as lean as possible, at the cost of special-casing them and
> removing things like the footer, JS, etc., or we'll need to make mozilla.com
> more performant as a whole. There are a handful of things that can be done
> (like minifying all JS and CSS, which we only partly do at the moment), not
> using YUI *and* jQuery, and so on. But that probably needs to be part of a more
> general "realign mozilla.com" project that'll have to deal with a bunch of
> legacy resources as well.

I agree.  For example, would we really want to embed CSS and JS in all our mozilla.com pages?  How could that be done in code, in a clean and reusable way?  Should we compromise on 1 request each for CSS and JS?  

On the other hand, if we only have a few main download pages that don't change often, having special HTML/CSS/JS implementations for them wouldn't be too bad, as long as the design isn't too inconsistent.  

Mainly, I just want to make sure we think about how to implement test winners in production, and how the changes affect the usual code and process, especially when the implementation and design are radically different, like this one.
(Reporter)

Comment 8

8 years ago
We're only showing the experiment to IE users, so detecting the OS shouldn't matter, right?  Do IE users get different download files?
(Reporter)

Comment 9

8 years ago
One more thing.  Can we change the "Awards" background image to the trophy?
(In reply to comment #9)
> One more thing.  Can we change the "Awards" background image to the trophy?

I'll have to make an image for that (the three boxes are in the same image, and I don't think any other page has this content in this order), but yes we can.

I'll work on this tomorrow again (my time), but if Alex is faster, he's welcome to fork the code and add some of this (or commit it to SVN). Thanks!
(In reply to comment #8)
> We're only showing the experiment to IE users, so detecting the OS shouldn't
> matter, right?  Do IE users get different download files?

True, I forgot this is IE.html.  There is only 1 windows build, so hard-coding that should be fine.

We should use product-details for the version number though, in case any new version is released during the cycle of this test.
(Reporter)

Comment 12

8 years ago
Okay, can you make that change Alex?  I'd like to push this test live tomorrow (if possible).
(In reply to comment #7)
> I agree.  For example, would we really want to embed CSS and JS in all our
> mozilla.com pages?  How could that be done in code, in a clean and reusable
> way?  Should we compromise on 1 request each for CSS and JS?  

Inlining CSS & JS is good for a landing pages (homepage or dl page). For normal pages I wouldn't recommend it because you lose benefits of caching. We can do it in a clean, reusable way like this:

<style type="text/css">
<?php include('css/style.css');?> etc. 
</style>
same for js.

Then we can post-load the files used for the rest of the site with a tiny bit of inline js.

window.attachEventListener('load', function() { //append js and css file to dom});
Keywords: perf
(In reply to comment #13)
> Inlining CSS & JS is good for a landing pages (homepage or dl page). 

Yes, sounds good.

> For normal
> pages I wouldn't recommend it because you lose benefits of caching. 

Could you be more specific?

>We can do
> it in a clean, reusable way like this:
 
> <style type="text/css">
> <?php include('css/style.css');?> etc. 
> </style>

Could be abstracted into a function

> same for js.
> 
> Then we can post-load the files used for the rest of the site with a tiny bit
> of inline js.
> 
> window.attachEventListener('load', function() { //append js and css file to
> dom});

And if the user doesn't have JS enabled?

Thanks, good suggestions.
(In reply to comment #14)
> > For normal
> > pages I wouldn't recommend it because you lose benefits of caching. 
> 
> Could you be more specific?

If you always inline all CSS & JS for all pages you wouldn't get the benefit of if you had external files and used far-future expires headers. Users would re-download the same content again and again. Pages that don't need to be optimized to the max (features, help, etc) probably don't need inlined js & css.


> > <style type="text/css">
> > <?php include('css/style.css');?> etc. 
> > </style>
> 
> Could be abstracted into a function

Yep!


> And if the user doesn't have JS enabled?

That's fine, then if they go to another page on mozilla.com that has external stylesheets and js they just have to download them instead of already having them in their cache.
(In reply to comment #15)
> If you always inline all CSS & JS for all pages you wouldn't get the benefit of
> if you had external files and used far-future expires headers. Users would
> re-download the same content again and again. Pages that don't need to be
> optimized to the max (features, help, etc) probably don't need inlined js &
> css.

Right, good point.
 
> That's fine, then if they go to another page on mozilla.com that has external
> stylesheets and js they just have to download them instead of already having
> them in their cache.

Ah, I see, I misunderstood the point of that code.  Basically, you're prefetching the CSS and JS for the majority of the site, right?
(In reply to comment #16)
> Ah, I see, I misunderstood the point of that code.  Basically, you're
> prefetching the CSS and JS for the majority of the site, right?

Yep!
I made the changes to both the background image at the bottom as well as adding the nav items at the top. Committed to r65012.

I can push this to prod via kubla -- then it'd show up under:
http://www.mozilla.com/firefox/ie-perf.html
I just pushed the current status of the page live, should show up shortly.
Thanks Fred!  I hear this page is making big results already: 14% improvement in download conversions with a 99% confidence 

I think we're done here, reopen if I'm wrong
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(In reply to comment #20)
> Thanks Fred!  I hear this page is making big results already: 14% improvement
> in download conversions with a 99% confidence 

<3
(Assignee)

Comment 22

8 years ago
Since this page eliminated all JavaScript, it broke the download process for IE users.

The download buttons on mozilla.com push people to download.html (with URL vars indicating the product/platform/version). That page then auto-starts the download.

However, in IE you can't start a download with a non-user-initiated event without getting a security warning, so for IE visitors, the page WITH the download button (ie.html, home page, etc.) actually loads another window briefly to start the download, and then redirects to the download.html page. The download.html page itself doesn't actually start the download for IE users.

So, in this test, I think IE users (everyone in this test, right?) would have been taken to the download.html page when they clicked the download button. However, the download wouldn't have actually started, despite them seeing this message:

 "Thanks for choosing Firefox! Your download should automatically begin in a few seconds, but if not, _click here_."

I'd assume that the test for this page was only checking to see if people made it to the download.html page, not if the download actually started?
(Reporter)

Comment 23

8 years ago
That's right. We stopped the test last week, so this problem isn't currently affecting users.  Did we just miss this error? https://bugzilla.mozilla.org/show_bug.cgi?id=555772.
(Reporter)

Comment 24

8 years ago
Created attachment 438634 [details]
Button JS

Steven, can I get a version of this page that fixes the bug you identified?  I need to use this page as the control for my next test: https://bugzilla.mozilla.org/show_bug.cgi?id=556605

I've attach some of the relevant code (I think).
(Reporter)

Updated

8 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 25

8 years ago
(In reply to comment #24)
> Steven, can I get a version of this page that fixes the bug you identified?  I
> need to use this page as the control for my next test:
> https://bugzilla.mozilla.org/show_bug.cgi?id=556605

I've updated ie-perf.html with these fixes in trunk in r65696. You can see the changes here: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/firefox/ie-perf.html?r1=65017&r2=65696
(Reporter)

Comment 26

8 years ago
Thanks.  Do we need to QA this now?
I get this warning in IE when i try to access trunk http://www.screencast.com/users/retornam/folders/Jing/media/d07af785-e7f0-4a94-b26d-962cf1f27e73
Raymond: try just regular HTTP?
looks good on HTTP
(In reply to comment #27)
> I get this warning in IE when i try to access trunk
> http://www.screencast.com/users/retornam/folders/Jing/media/d07af785-e7f0-4a94-b26d-962cf1f27e73

Pretty sure this is a regression, I would expect that page to load over ssl properly.
(Assignee)

Comment 31

8 years ago
(In reply to comment #30)
> Pretty sure this is a regression, I would expect that page to load over ssl
> properly.

This page was originally setup including full paths for images (including "http://") - so there are hard-coded non-SSL links in the page.

Updated

8 years ago
Assignee: fwenzel → steven
Keywords: perf
Whiteboard: [perf]
(Assignee)

Comment 32

7 years ago
This page doesn't exist anymore.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago7 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
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.