The document summarizes techniques for achieving AMP-like page speed performance without fully validating as AMP. It discusses limiting round trips for CSS and JavaScript files, pre-rendering content, only using GPU-accelerated animations, stating resource sizes explicitly, and performing DOM operations in a way that mimics the AMP runtime. The presentation provides alternatives and compares them to AMP requirements to achieve fast page loads without all the constraints of valid AMP markup.
3. @Suzzicks MobileMoxie #SMXMunich
AMP: Accelerated Mobile
Pages Project
• Framework for speed
• Built for static content
@Suzzicks MobileMoxie #SMXMunich
4. @Suzzicks MobileMoxie #SMXMunich
AMP: Accelerated Mobile
Pages Project
• Framework for speed
• Built for static content
• At the moment, primarily used by
major news publishers like:
@Suzzicks MobileMoxie #SMXMunich
9. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
</>
.html
@Suzzicks MobileMoxie #SMXMunich
• Standardizes Common Site
Features
10. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
</>
.html
@Suzzicks MobileMoxie #SMXMunich
{ }
.CSS
• Standardizes Common Site
Features
11. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
</>
.html
@Suzzicks MobileMoxie #SMXMunich
{ }
.CSS
{ ; }
.js
• Standardizes Common Site
Features
12. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
AMP-HTML
HTML
• Standardizes Common Site
Features
• Limits Reliance on Inefficient
Code
13. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
VS
• Standardizes Common Site
Features
• Limits Reliance on Inefficient
Code
• Requires Efficient Caching
14. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
• Standardizes Common Site
Features
• Limits Reliance on Inefficient
Code
• Requires Efficient Caching
• Requires Efficient
Compression
15. @Suzzicks MobileMoxie #SMXMunich
AMP Addresses Many Problems of Modern Code
AMP-HTML Webpage
AMP JS Run-time
• Standardizes Common Site
Features
• Limits Reliance on Inefficient
Code
• Requires Efficient Caching &
Compression
• Adds Intelligent Runtime &
Pre-Render
28. @Suzzicks MobileMoxie #SMXMunich
Chrome Plugin AMP Validation bit.ly/validateAMP
1. Open your page in your browser
2. Add “#development=1” to the URL, for example,
http://localhost:8000/released.amp.html
#development=1.
3. Open the Chrome DevTools Console & check for errors.
32. @Suzzicks MobileMoxie #SMXMunich@Suzzicks MobileMoxie #SMXMunich
http://www.technicalseo.info/seo-tools/amp/ http://bit.ly/AMP-Tool
Detects the Presence of AMP Code but
Does Not Actually Validate for
Appearance in Google Results!!!!
Good for Testing Intentional Non-
Validating AMP Pages
39. @Suzzicks MobileMoxie #SMXMunich
“AMP Is Not Faster Than What You Can Do If You Really
Know What You’re Doing.” - Malte Ubl, AMP Tech Lead
https://youtu.be/hVRkG1CQScA
47. @Suzzicks MobileMoxie #SMXMunich
Limit Round Trip Requests for CSS
Best
Alternative
Good
Alternative
Max 50 KB/ page of CSS All
Inline – Limited Selectors &
Classes
Inline Above The Fold CSS &
Use a Deferred CSS for
Below The Fold. Combine &
Minify;
PreConnect Font Requests
or Host fonts on CDN
Ϟ AMP Requirement
Only Inline CSS, no More
than 50 KB per page –
Limited Selectors &
Classes
(Zero HTTP Requests before
Fonts Start Downloading)
48. @Suzzicks MobileMoxie #SMXMunich
Limit Round Trip Requests for CSS
Best
Alternative
Good
Alternative
Max 50 KB/ page of CSS All
Inline – Limited Selectors &
Classes
Inline Above The Fold CSS
and Use a Deferred CSS for
Below The Fold. Combine &
Minify;
PreConnect Font Requests
or Host fonts on CDN
Ϟ AMP Requirement
Zero HTTP Requests
before Fonts Loaded &
Only Inline CSS, no More
than 50 KB per page
PreConnect for Web Fonts in HTML:
PreConnect for Web Fonts in JavaScript:
49. @Suzzicks MobileMoxie #SMXMunich
Limit Round Trip Requests for CSS
Best
Alternative
Good
Alternative
Max 50 KB/ page of CSS All
Inline – Limited Selectors &
Classes
Inline Above The Fold CSS
and Use a Deferred CSS for
Below The Fold. Combine &
Minify;
PreConnect Font Requests
or Host fonts on CDN
Ϟ AMP Requirement
Zero HTTP Requests
before Fonts Loaded &
Only Inline CSS, no More
than 50 KB per page
PreConnect for Web Fonts in HTML:
PreConnect for Web Fonts in JavaScript:
50. @Suzzicks MobileMoxie #SMXMunich
Limit Round Trip Requests for CSS
Best
Alternative
Good
Alternative
Max 50 KB/ page of CSS All
Inline – Limited Selectors &
Classes
Inline Above The Fold CSS
and Use a Deferred CSS for
Below The Fold. Combine &
Minify;
PreConnect Font Requests
or Host fonts on CDN
Ϟ AMP Requirement
Zero HTTP Requests
before Fonts Loaded &
Only Inline CSS, no More
than 50 KB per page
PreConnect for Web Fonts from an HTTP Header:
51. @Suzzicks MobileMoxie #SMXMunich
Limit Round Trip Requests for CSS
Best
Alternative
Good
Alternative
Max 50 KB/ page of CSS All
Inline – Limited Selectors &
Classes
Inline Above The Fold CSS
and Use a Deferred CSS for
Below The Fold. Combine &
Minify;
PreConnect WebFont
Requests or Host fonts on
CDN
Ϟ AMP Requirement
Zero HTTP Requests
before Fonts Loaded;
Only Inline CSS, no More
than 50 KB per page
In .htaccess or httpd.config add this code:
# Apache config
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
# nginx config
if ($filename ~* ^.*?.(eot)|(ttf)|(woff)$){
add_header Access-Control-Allow-Origin *;
}
(Works only in WebKit browsers, not FireFox)
54. @Suzzicks MobileMoxie #SMXMunich
PreRender Content by Viewport
Best
Alternative
Good
Alternative
<link rel="preRender
preFetch”
href=”http://www.NextPage/
page”>
<link rel="preRender”
href=”http://www.NextPage
p.com/page”>
Ϟ AMP Requirement
PreRender Next Low-CPU,
In-Viewport Content
(Invisible Tab of Rendered Page Content)
55. @Suzzicks MobileMoxie #SMXMunich
PreRender Content by Viewport
Best
Alternative
Good
Alternative
<link rel="preRender
preFetch”
href=”http://www.NextPage/
page”>
<link rel="preRender”
href=”http://www.NextPage
p.com/page”>
Ϟ AMP Requirement
PreRender Next Low-CPU,
In-Viewport Content
(Invisible Tab of Rendered
Content)
preRender= HTML Page + Dependent Files
preFetch = HTML Page Only (Needed for FireFox)
56. @Suzzicks MobileMoxie #SMXMunich
Great Post about Rel-Prerender:
http://ipullrank.com/how-i-sped-up-my-site-68-percent-with-one-line-of-code/
@Suzzicks MobileMoxie #SMXMunich
http://bit.ly/MikeKingRocks
58. @Suzzicks MobileMoxie #SMXMunich
Loading of External JavaScript
Best
Alternative
Good
Alternative
Use the AMP JavaScript
Library & Modify as
Necessary; Load
Asynchronously
Utilize Both Async & Defer
Attributes for ALL External
JavaScript
Ϟ AMP Requirement
All External JavaScript are
Loaded Async from the
AMP JavaScript Library
59. @Suzzicks MobileMoxie #SMXMunich
Loading of External JavaScript
Best
Alternative
Good
Alternative
Use the AMP JavaScript
Library & Modify as
Necessary; Load
Asynchronously
Utilize Both Async & Defer
Attributes for ALL External
JavaScript
Ϟ AMP Requirement
All External JavaScript are
Loaded Async from the
AMP JavaScript Library
Synchronous Loading= Scripts Download in Parallel & Execute in Source
Code Order. Blocks Rendering Until Execution is Complete (Normal - No
Benefit)
Defer= Scripts are Downloaded in Parallel & Executed in Source Code
Order after the Entire Document is parsed. No Impact on Scripts without
“src” or Scripts that are dynamically added. Flakey in some Browsers
(Some Benefit)
Async = Does not wait until the Document has parsed to execute. Scripts
are Downloaded in Parallel & Executed ASAP (Best Benefit – HTML5 is
Awesome!)
60. @Suzzicks MobileMoxie #SMXMunich
Loading of External JavaScript
Best
Alternative
Good
Alternative
Use the AMP JavaScript
Library & Modify as
Necessary; Load
Asynchronously
Utilize Both Async & Defer
Attributes for ALL External
JavaScript
Ϟ AMP Requirement
All External JavaScript are
Loaded Async from the
AMP JavaScript Library
Defer & Async at the Same Time:
W3C Says: “The defer attribute may be specified even if the async attribute is specified, to cause legacy Web
browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous
blocking behavior that is the default.”
61. @Suzzicks MobileMoxie #SMXMunich
Loading of External JavaScript
Best
Alternative
Good
Alternative
Use the AMP JavaScript
Library & Modify as
Necessary; Load
Asynchronously
Utilize Both Async & Defer
Attributes for ALL External
JavaScript
Ϟ AMP Requirement
All External JavaScript are
Loaded Async from the
AMP JavaScript Library
BUT:
If You Need to get an AMP page to Validate, and 3rd party JS is the only thing
stopping you – Put it in a Sandboxed iFrame
(Really, anything that is preventing you from validating for AMP can be put in the
AMP-iFrame)
62. @Suzzicks MobileMoxie #SMXMunich
Static Resource Sizing
Best
Alternative
Good
Alternative
Include Height & Width
Dimensions for ALL Page
Elements & include HTML5
Tags like <picture> with the
Srcset
Include Height & Width
Dimensions for MOST Page
Elements & include HTML5
Tags like <picture> with the
Srcset. Keep the Design
Simple
Ϟ AMP Requirement
Resource Sizes Must be
Stated Explicitly
(But can Still Be
Responsive)
63. @Suzzicks MobileMoxie #SMXMunich
Minimal Style Recalculations
Best
Alternative
Good
Alternative
Use a Fastdom Regulatory
Layer so that All the ‘Reads’
Happen 1st, Then All the
‘Writes’
Perform Limited DOM
Batching Operations using
jQuery
Ϟ AMP Requirement
All DOM ‘Read’
Operations Done 1st,
Then All ‘Write’
Operations in the AMP
Runtime
64. @Suzzicks MobileMoxie #SMXMunich
Only GPU-Accelerated Animations
Best
Alternative
Good
Alternative
Selectively Promote
Animation Elements & Use
the ‘Transform’ Declaration:
[translateZ(0);] to Trigger
GPU Acceleration
Promote ALL Animation
Elements Indiscriminately &
Use the ‘Transform’
Declaration: [translateZ(0);]
to Trigger GPU Acceleration
Ϟ AMP Requirement
Only ‘Transform’ &
‘Opacity’ CSS Animations
& Must be GPU -
Accelerated. No Layout-
Changes
- GPU = Graphics Processing Unit
- Leverages Hardware Graphic Processing Rather than the
Browser
- GPU Acceleration was Created for 3D Graphics, but Can Be
Tricked into Use for Speed of CSS Graphics
- CSS Animations should Not Change Layout, to Avoid Adding
more Layout Recalculations – That is why ‘Transform’ &
‘Opacity’ are the only ones allowed in AMP
65. @Suzzicks MobileMoxie #SMXMunich
Only GPU-Accelerated Animations
Best
Alternative
Good
Alternative
Selectively Promote
Animation Elements & Use
the ‘Transform’ Declaration:
[translateZ(0);] to Trigger
GPU Acceleration
Promote ALL Animation
Elements Indiscriminately &
Use the ‘Transform’
Declaration: [translateZ(0);]
to Trigger GPU Acceleration
Ϟ AMP Requirement
Only ‘Transform’ &
‘Opacity’ CSS Animations
& Must be GPU -
Accelerated. No Layout-
Changes
69. @Suzzicks MobileMoxie #SMXMunich
Leverage HTTP2 Effectively
Best
Alternative
Good
Alternative
Update Site for HTTPS &
Servers for HTTP2
Begin Transition to HTTPS &
Planning for HTTP2
Ϟ AMP Requirement
HTTP2 Required
71. @Suzzicks MobileMoxie #SMXMunich
Extending AMP Caching Benefits
One AMP Validating Page
Holds All External Elements
Google’s FREE AMP Caches
Non-AMP Pages
on the Same Site
72. @Suzzicks MobileMoxie #SMXMunich
Leverage Caching Effectively
Best
Alternative
Good
Alternative
Still…Use Google’s Free AMP
Proxy Caches
Set all Static Content to
Cache for a Year. Use File
Management Software to
Update File Names &
Prevent Stale Content
Ϟ AMP Requirement
Use Google’s Free AMP
Proxy Caches or a CDN
Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.
Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.
Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.
Responsive Design is Good but Not THE Answer
Often Slow – Especially on Mobile
Won’t Work on Tiny Screens like Watches
Developers were Getting Too Creative with JS Functionality
Responsive Design is Good but Not THE Answer
Often Slow – Especially on Mobile
Won’t Work on Tiny Screens like Watches
Developers were Getting Too Creative with JS Functionality
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
AMP Addresses Many Problems of Modern Code
Standardizes Common Site Features
HTML
CSS
JS
Limits Reliance on Inefficient Code
Requires Efficient Caching & Compression
Adds Intelligent Runtime & Pre-Render
Optimize data delivery
https://upload.wikimedia.org/wikipedia/commons/8/87/Efficiency.png
Getting AMP-like performance is about adopting a development philosophy where hygiene is of the utmost importance.
https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/
See point one for the CDN option under “good”: https://davidwalsh.name/font-loading
https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/
See point one for the CDN option under “good”: https://davidwalsh.name/font-loading
https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/
See point one for the CDN option under “good”: https://davidwalsh.name/font-loading
https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/
See point one for the CDN option under “good”: https://davidwalsh.name/font-loading
https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/
See point one for the CDN option under “good”: https://davidwalsh.name/font-loading
Users notice if sites and apps don't run well, so optimizing rendering performance is crucial!
Img: https://pixabay.com/en/browser-web-www-computer-773215/
Source for “best” – Malte’s response to an answer here: http://stackoverflow.com/questions/35133669/details-on-pre-rendering-with-amp-html
For “ Good,” maybe reference Mike King’s post for more details on rel-prerender tag: http://ipullrank.com/how-i-sped-up-my-site-68-percent-with-one-line-of-code/ (Saying “Good” because it doesn’t seem as AMP-esque as the statement by Malte in the StackOverflow exchange).
Source for “best” – Malte’s response to an answer here: http://stackoverflow.com/questions/35133669/details-on-pre-rendering-with-amp-html
For “ Good,” maybe reference Mike King’s post for more details on rel-prerender tag: http://ipullrank.com/how-i-sped-up-my-site-68-percent-with-one-line-of-code/ (Saying “Good” because it doesn’t seem as AMP-esque as the statement by Malte in the StackOverflow exchange).
Optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.
Source for good (it says complications can arise when fastdom is used on third-party scripts): https://github.com/wilsonpage/fastdom/issues/65
http://www.htmlgoodies.com/beyond/reference/performing-batch-dom-operations-using-jquery.html
This seems somewhat disputed.
A Treehouse article says to follow the recommendation I’ve stated above: http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css
But StackOverflow has people contesting it, offering other ideas: http://stackoverflow.com/questions/10814178/css-performance-relative-to-translatez0
If you go to Google Developers, it looks like the approach above is okay, so long as you’re careful about understanding the layers of your app and not promoting elements unnecessarily: https://developers.google.com/web/fundamentals/performance/rendering/stick-to-compositor-only-properties-and-manage-layer-count
This seems somewhat disputed.
A Treehouse article says to follow the recommendation I’ve stated above: http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css
But StackOverflow has people contesting it, offering other ideas: http://stackoverflow.com/questions/10814178/css-performance-relative-to-translatez0
If you go to Google Developers, it looks like the approach above is okay, so long as you’re careful about understanding the layers of your app and not promoting elements unnecessarily: https://developers.google.com/web/fundamentals/performance/rendering/stick-to-compositor-only-properties-and-manage-layer-count
This would be kind of bonus info about content efficiency because HTTP/2 isn’t really referenced in talks specific to AMP. The spirit of it is in line with AMP’s emphasis on speed, though, particularly the two elements I singled out here. (There are others. I would couch this by being like “HTTP/2 is really its own talk, but here are two pieces that are cool to quickly cover.” )
Photo: https://i.ytimg.com/vi/M7ZQP0aTfIM/maxresdefault.jpg
ALT: https://c1.staticflickr.com/5/4028/4397111144_2cfacd3fc0_b.jpg
No head of line blocking
Now a logical stream – all streams share this connection, multiplexed on this single connection
Img source: HTTP/2 101 (Chrome Dev Summit 2015)
HTTP/2 101 (Chrome Dev Summit 2015) – Around 15:20
HPACK – Header compression specifically for HTTP
Img source:
This seems somewhat disputed.
A Treehouse article says to follow the recommendation I’ve stated above: http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css
But StackOverflow has people contesting it, offering other ideas: http://stackoverflow.com/questions/10814178/css-performance-relative-to-translatez0
If you go to Google Developers, it looks like the approach above is okay, so long as you’re careful about understanding the layers of your app and not promoting elements unnecessarily: https://developers.google.com/web/fundamentals/performance/rendering/stick-to-compositor-only-properties-and-manage-layer-count
This seems somewhat disputed.
A Treehouse article says to follow the recommendation I’ve stated above: http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css
But StackOverflow has people contesting it, offering other ideas: http://stackoverflow.com/questions/10814178/css-performance-relative-to-translatez0
If you go to Google Developers, it looks like the approach above is okay, so long as you’re careful about understanding the layers of your app and not promoting elements unnecessarily: https://developers.google.com/web/fundamentals/performance/rendering/stick-to-compositor-only-properties-and-manage-layer-count