500849 - Improve ySlow scores for Mozilla.com

Status: RESOLVED FIXED

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

Description

[Michael Morgan [:morgamic]]

Attachment: html showing yslow scores

mozilla.com is very poor when it comes to reducing overhead and is not optimized.  We need to move images, css, etc. to separate domains and reduce the overall # of HTTP requests on the site.

Comment 3

[Ryan Doherty (:rdoherty)]

Any updates on this? I was just reading:
http://www.stevesouders.com/blog/2009/07/27/wikia-fast-pages-retain-users/

and for us it most likely means faster site == more Firefox downloads.

Comment 4

[Laura Mesa [:lmesa] [:lvmesa]]

Any news on this bug?

Comment 5

[Michael Morgan [:morgamic]]

I think we should have a sprint dedicated to performance in Sept.

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #5)
> I think we should have a sprint dedicated to performance in Sept.

+1 and all that jazz.

Comment 7

[Blake Cutler]

Would it be feasible/worthwhile to track how speed improvements affect user behavior?  An A/B test would be ideal.  Doing so would help us determine how much effort we should dedicate to improving performance.

Comment 8

[Ryan Doherty (:rdoherty)]

(In reply to comment #7)
> Would it be feasible/worthwhile to track how speed improvements affect user
> behavior?  An A/B test would be ideal.  Doing so would help us determine how
> much effort we should dedicate to improving performance.

I think it's a great idea. And I have seen many reports of how slower pages == higher abandonment, less purchases/downloads, etc.

Comment 9

[Michael Morgan [:morgamic]]

Not sure if it's a good use of time to do an A/B test for this.  We can all agree that on some level page load times and performance affect adoption.  Is it really important to know how much?  Fixing this bug is something we should just do -- on top of the obvious side effects we also have to uphold the Mozilla standard for sites and make sure our sites are good examples of proper design and implementation.

That said, if we want to do a case study and compare before/after statistics, that's great.  I'm fine with incrementally improving site performance and monitoring downloads, etc. to see how they helped, but a live A/B test is probably overkill.

Comment 10

[Ryan Doherty (:rdoherty)]

wfm

Comment 11

[Blake Cutler]

This data could be valuable in influencing future design decisions--particularly on the en-US/firefox page.  That said, performance is something we can test more easily down the line, once SiteSpect is set up. An A/B test probably isn't worthwhile here.

Comment 12

[Michael Morgan [:morgamic]]

I'm mostly not a fan of having an unoptimized and optimized version running in parallel.  Very difficult to do technically since most perf improvements are global.  It'd be a non-trivial amount of time spent towards catering to the A/B test and that's my main concern.  When is SiteSpect going live?

Comment 13

[Blake Cutler]

Thanks for the background. The plan is to have it live by the end of next week.

Comment 14

[Ryan Doherty (:rdoherty)]

Attachment: v1

Half hour of work == 13 YSlow points!

Comment 15

[Ryan Doherty (:rdoherty)]

(In reply to comment #14)
> Created an attachment (id=405003) [details]
> v1

The files I edited were includes/header.inc.php, .htaccess and /includes/min/config.php, /includes/min/groupsConfig.php. The rest is Minify code.

Comment 16

[Michael Morgan [:morgamic]]

Comment on attachment 405003 [details] [diff] [review]
v1

I like this, and it has minimal PHP overhead.  We should use memcache-driven caching in lieu of file-based caching to get better hit rates internally.  Other than that, this is great work!  Thanks Ryan!

Comment 17

[Ryan Doherty (:rdoherty)]

Attachment: v2

Now with memcache! (Code degrades to file-based cache if it can't connect to a memcache server)

Comment 18

[Michael Morgan [:morgamic]]

Comment on attachment 406230 [details] [diff] [review]
v2

Works as advertised, but add the php_value lines to the patch and I think we're good.

Comment 19

[Ryan Doherty (:rdoherty)]

Attachment: v3

final patch

Comment 20

[Ryan Doherty (:rdoherty)]

r53584

I don't dare push this live on a friday afternoon. Planning on Monday.

Comment 21

[Michael Morgan [:morgamic]]

We should QA this at least.

Comment 22

[Ryan Doherty (:rdoherty)]

(In reply to comment #21)
> We should QA this at least.

Yeah, and it will need IT support to put memcache config into config.php.

Comment 23

[Les Orchard [:lorchard]]

FWIW, this is coming up blank:

https://www-trunk.stage.mozilla.com/includes/min/?g=css
https://www-trunk.stage.mozilla.com/includes/min/?g=js

Would that be caused by a lack of memcache config?

Comment 24

[Ryan Doherty (:rdoherty)]

(In reply to comment #23)
> FWIW, this is coming up blank:
> 
> https://www-trunk.stage.mozilla.com/includes/min/?g=css
> https://www-trunk.stage.mozilla.com/includes/min/?g=js
> 
> Would that be caused by a lack of memcache config?

Shouldn't be, it falls back to file-based caching if it can't connect to memcache. Will investigate.

Comment 25

[Reed Loden [:reed]]

This broke my staging environment, which is making it hard for me to review bug 454299.

Comment 26

[Reed Loden [:reed]]

Looks like the problem is that this patch made php-pecl-memcache a prereq, which is unfortunate. Installing it on my test server fixed the issue I was having.

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #26)
> Looks like the problem is that this patch made php-pecl-memcache a prereq,
> which is unfortunate. Installing it on my test server fixed the issue I was
> having.

You want bug 522828.

Comment 28

[Reed Loden [:reed]]

(In reply to comment #27)
> You want bug 522828.

Originally, no, but I just morphed that bug into what I want, so ok.

Comment 29

[Ryan Doherty (:rdoherty)]

(In reply to comment #26)
> Looks like the problem is that this patch made php-pecl-memcache a prereq,
> which is unfortunate. Installing it on my test server fixed the issue I was
> having.

I've added a check for memcache, so this shouldn't be a problem for people without memcache support in php.

I'm re-opening this because there are some things we probably could do to improve YSlow scores even more.

Comment 30

[Ryan Doherty (:rdoherty)]

r53749 removes 1 more JS file (merged stats js in footer into 1 file). 

Up to a 77 on trunk.

Comment 31

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #30)
> r53749 removes 1 more JS file (merged stats js in footer into 1 file). 
> 
> Up to a 77 on trunk.

Verified: Grade C Overall performance score 77	Ruleset applied: YSlow(V2)	URL: https://www-trunk.stage.mozilla.com/en-US/

Comment 32

[Michael Morgan [:morgamic]]

Should we resolve?

Comment 33

[Ryan Doherty (:rdoherty)]

(In reply to comment #32)
> Should we resolve?

I want to push the new code live and leave this bug open. I won't be happy until we get an A for the homepage.

Comment 34

[Michael Morgan [:morgamic]]

So... how is this different from bug 557562?

Comment 35

[Alex Buchanan [:abuchanan]]

(In reply to comment #34)
> So... how is this different from bug 557562?

Ya, they're pretty much the same thing, although that bug will take it slightly further by inlining CSS and JS completely, and focuses only on 3 landing pages, while this is more general.  I guess it's a subset of this bug.

ANYwho, if there's no actionable items in this bug, let's close it out, or set a list of things to do next.

Comment 36

[Anthony Ricaud (:rik)]

No actionable items? Closing ! :)