Optimizing Your Frontend Performance - Presentation Transcript
PHPNW09
Thomas Weinert
Optimizing Your Frontend Performance
About Me
● Application Developer
– PHP
– XSLT/XPath
– (some) Javascript
● papaya CMS
– PHP based Content Management System
– uses XSLT for Templates
How to scale you webpage?
● Hardware
● Backend
● Frontend
Hardware
● More hardware
● Better hardware
● Moores Law
– Transistors doubling every 18 months
– Transistors != Performance
● Distributed systems are complex
● Think about environment
Backend
● External data sources are slow
– SQL
– Files
– Network
● Locking is slower
● Memory is faster
– but less secure
Mini/Micro Optimisations
● Myths
– echo vs. print
– ' vs. "
● Objects vs. functions vs. linear source
● Template systems
Mini/Micro Optimisations
DON'T DO IT
Yahoo!
● Yahoo!'s Exceptional Performance team
– Yahoo!'s Exceptional Performance team
evangelizes best practices for improving web
performance. They conduct research, build tools,
write articles and blogs, and speak at conferences.
Their best practices center around the rules for high
performance web sites.
– http://developer.yahoo.com/performance/
Results
● 80% of the end-user response time is spent on
the front-end.
CSS Sprites
● Elements with fixed size
● Background image
● Disable repeat
● Negative positions
CSS Icons
● Raster of icons
● No repeat
● Fixed size
<div> or <span>
CSS Backgrounds
● Gradient
● Repeat in one
direction
Minify Javascript
● Most JS libraries provide a minified version
● YUI Compressor:
http://developer.yahoo.com/yui/compressor/
– JS and CSS
● Packer
– Webpage, .Net, Perl, PHP
– http://dean.edwards.name/packer/
#2 Use A CDN
● Content Delivery Network
– Akamai Technologies
– Mirror Image Internet
– Limelight Networks
● Bring the content to your users
– Geographic distance
– Physics is still here
● Only for large sites
● Dynamic content is complex
Configure ETags
● Browser still asks webserver
● Server specific
– CDN
– Load balancer with multiple servers
● Apache
– FileETag none
● IIS
– http://support.microsoft.com/?id=922733
Split requests across domains
● HTTP 1.1 suggests 2 parallel requests per
domain
● Separate content by function
– www.domain.tld
– themes.domain.tld
– usercontent.domain.tld (security)
● Optimisation tools change the option
● Consider cookie domains
Reduce DNS Lookups
● DNS maps host names to ips
● Needs time
– 20-120 milliseconds
● Cached in browser
Avoid Redirects
● Obviously addition requests
● Only cached with explicit headers
● http://www.domain.tld
– → http://www.domain.tld/
Put Stylesheets at the Top
● Progressive display of the page
● Page appears to load faster
● W3C specifications
Put Scripts at the Bottom
● Scripts block parallel downloads
– defer attribute in MSIE
● onload() event
– used by most libraries
● Problem: document.write()
– Counter
– Banners
JavaScript And CSS Files
● Do not embed JS/CSS in your pages
– No <script>...</script>
– No <style>...</style>
● Seperate caching headers
● Revision parameter (style.css?rev=1234)
– Get parameter
– Unique URL for browser
– Possibly in path/filename
Remove Duplicate Scripts
● Team size
● Standard scripts
– XMLRPC, JQuery, Prototype
● Script module for your template system
● $templatesystem->addScript('foo.js');
Make Ajax Cacheable
● Often AJAX applications avoid caching
– http://some.domain.tld/ajax.file?t=randomvalue
● A lot of requests
● Use more static URLs
References
● Slides: http://www.a-basketful-of-papayas.net/
● Yahoo Performance Team
– http://developer.yahoo.com/performance/
● Google Page Speed
– http://code.google.com/intl/en-UK/speed/page-speed/
● Apache GZIP
– http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
● No Etag in IIS
– http://support.microsoft.com/?id=922733
0 comments
Post a comment