Design for performance

Performance KILLS: 400 ms -> 1% reduction in search volume Reduction persisted even after the latency was removed. Review of the google data, other data that shows user adoption & loyalty effected by performance. Distribution: search engines care about it now Partners: cut-offs when you are on other platforms (Facebook, linkedin)
90% of time is spent waiting for css, js, image, flash files in a page to download. (>>>IMG THAT SHOWS THIS<<<) It's *theoretically* easier to fix client-side performance than server-side performance. Classic 80/20 rule … 80% of the output from 20% of the input. So this is where you want to focus. 100% left-brain anayltical, using straightforward rules of thumb. But requires whole team (web designers , front end devs, server devs, and ops) to work together to get right.
Series of 10 recommendations from Steve Souters that are baked into YSlow tool. Brilliant way to get your ideas across. You don't even really need to read the book, just using the tool will push you in the right direction. I'm only going to talk about the top 3, because they're listed in decreasing importance.
1) REDUCE HTTP REQUESTS
1) REDUCE HTTP REQUESTS
- Merge images into one, show parts of the image using css. //SHOW SPRITE IMAGE
Unfortunately, a lot of social sites are fibered here. Navigational images can easily be sprited into a single image. But a bunch of faces or a bunch of thumbnails of related content can't. Dave McClure &quot;Faces&quot; image.
The FACES are the problem
FACES are a problem in ads as well. Ad images can occasionally be super-abusive (show post-nup show ad). Very difficult to track down if coming through an ad network. Ads can be abusive as well. Ad servers can stuff LOTS of random things into your page. Need to spot - check, remove ad networks who stuff with junk. Constance vigilance is required, only work with a couple ad networks that you really trust. If you think about what you're letting someone do by serving their own ad code, they can basically do whatever they want.
- Concatinate CSS files into one file (combined.css)- Concatinate JS files into one file (combined.js)
VIRALITY and ADS both come at a cost.
CDNs used to be very inapproachable for pre-funding startups. Now with Amazon CloudFront anyone can get CDN, and you *really* should.Things to be aware of: - Necessary for economics as well as performance. I can't share the prices we pay for bandwidth, but they are much less than amazon. So for a company that's using cloud infrastructure, a CDN is a cost-saving measure. - Use cloudfront or something else until your costs start to actually rise. - If you're not used to negotiating this is a much better environment to practice than when you're dealing with VCs. It's all about BATNA. Play vendors off against each other and watch the price drop. - There's 2 ways to pay for CDN: 95/5 and per-GB. 95/5 is too confusing, per-GB will let you understand and predict your costs a lot better - CDNs always want a &quot;commit&quot; of how much you will consume per month/year. Shoot for committing about 1/2 of what you're currently consuming. Lots of people have been burned by CDN vendros. - Integrations take longer than you think they will … a lot goes on behind the scenes. Our switch to Akamai took about 10 weeks, most of the time was on Akamai's side, tuning their network for our content- MEASURE USING EXTERNAL SERVICE NAME
This is basically an extension of rule 1, &quot;make fewer http requests&quot;. If you serve an asset locally, then you don't make a request.The difference between an asset being cached on the browser and being fetched via a CDN is like the difference between something being in memory vs on disk. It's HUGE. So don't do more work then you have to. So how do you stop the browser from requesting an image that it already has?When you serve up the image, set the following header: Cache-Control: max-age to a really high number. What this does is tell the browser that if it has had the resource specified by the given url for less that &quot;a really big number of seconds&quot;, then don't bother fetching it. Because it probably hasn't changed.
So what about when you want to change that resource? You're screwed, right? Well not really. The trick is to add a bogus parameter to the request. For example, you could link to /images/my_sprited_image?1123454. On a deployment that includes a change to that resource, increment the version number. New requests will go to /images/my_sprited_image?65432213. The date is the last time the file was edited. The second page load will serve the sprited image, merged css, and merged js from local disk, so it will be much faster. The faces and thumbnails will kind of add up over time, so that very frequent users will see the most benefit. For example, if you browse Facebook every day, then over time most of your friends faces will be served from disk. Once again, the other resources are out of your control: you can't effect the settings they use on their servers. ;-<
Basic problem anytime you embed anything from somebody else. They won’t be able to reliably change the link if they want to change the resource. As a result, they are unlikely to set a far-future expires header. This is why it’s a good idea to be very cautious about using third-party services for anything. Of course, with ads you don’t have a choice. Advertisers insist on running their own ad servers so they can independently verify that you are delivering the impressions you charge them for. Main culprit: ADS
Notice what a problem analytics is for external images. This is because, like ads, analytics only works if it is triggered on each page load. So it’s not possible to cache the images google and quantcast load and still perform the function that they are built for. Main culprit: ANALYTICS
Not as important as client-side performance. There's a good chance you think too much about this already!
Profile your code: build measurement directly into your app. Use tools like newrelic to understand performance.Don't work on the thing that isn't the bottleneck right now. Remember, premature optimization is the root of all evil. At any one time, there's probably at least one thing you're doing that's REALLY STUPID. Focus on finding that and fixing that.Measure and chart the web server performance as well >>SCREENSHOTS OF OPS PAGES<<<Measure the performance of the page from outside as well. There's lots of services like Gomez and ____ to do this, we use WebSitePulse to do this because they're super-cheap and measuring how long it takes a page to load is not rocket science.
1) CACHE THE HELL OUT OF EVERYTHING---Making web systems fast and scalable requires multiple layers of cacheWe already talked about two layers of cache, the browser cache and the CDN. On the server-side, there are two other caching layers that are releventA) MemCached (for objects). Obvious way to improve scalability and improve performance.Profile your use of memcached. We've found pages making hundreds of sequential fetches. In general you want to to cache at a course-grained level. Sets of objects rather than individual objects.//SHOW LIST OF MEMCACHED CALLS//SHOW CHART OF SPEEDUP AFTER WE REDUCED THEM
B) Varnish or another reverse proxy cache (for static pages)Ruby and other interpreted languages are slow.Once you generate the html, you should save it for the next time and serve it up from RAM instead of executing any logic.// SHOW CHART OF SPEEDUP FROM IMPLEMENTING VARNISH Cache invalidation is one of the harder software engineering problems to get right.Users don't have caching as part of their mental model. If they do an action and then don't see the result, they will freak out.
DO AS LITTLE WORK AS POSSIBLE AT RENDER TIMEPre-calculate things that are complicated (related content, leaderboards). Don't try to do it at render time. Dispatch work to be done later into a queue or database. Don't try to do it at render time.
Prefetching
-Don't try to do too much at once. Focus on the top YSlow rule, try to get an A or a B in that. Once you hit diminishing returns move to the next one down the list. Otherwise you risk doing a lot of work without moving the needle much. We made that blunder. -Performance is uniquely cross-functional. If your team is divided up into typical departments, like backend, frontend, operations, design, then you will NOT be able to move forward. You need to be able to have a designer work with a backend programmer and an ops person to troubleshoot performance problems.

Design for performance

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Design for performance

Ähnlich wie Design for performance (20)

Mehr von Warm Gun: Designing Happiness conference

Mehr von Warm Gun: Designing Happiness conference (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Design for performance

Hinweis der Redaktion