Conference talk presented at PHP South Coast 2017. Ten concrete ways to improve web performance, split between quick tactical wins and longer-term overarching strategies.

1. @AndrewRota

2. The web is no longer simply a
platform for serving static
documents.

3. Today we can build rich, highly
interactive applications on the
web.

5. And while users expect rich
interactivity, they also expect
performance.

7. Measure performance Reuse data
Load important resources first
Manage perceived
performance
Run less code Anticipate poor connections
Parallelize requests
Don’t try to do everything at
once
Only ask for what you need Send content as it’s ready

9. Tune performance based on data,
not guesses.

10. Types of performance tests
● Synthetic
● RUM

11. Synthetic performance metrics
● Measure performance in isolation
○ Tools: webpagetest, lighthouse
○ Use real devices if possible
○ Emulate network connections

12. A developer’s
browser/device/network are not
necessarily representative of their
users.

13. Common client testing mismatches
● Browser types and versions
● Device CPU power
● Network conditions
○ Bandwidth
○ Latency
○ Intermittent connections

14. Real User Metrics (RUM)
● CDNs and other services can collect
aggregate user performance data
● Data is less detailed, but more accurate
○ But influenced by outside factors.
● Problems will often manifest in the upper
90th percentile rather than the mean

21. Prioritize resources the user is likely
to need first (e.g., above the fold
images) before those they won’t
need until later.

22. Deprioritize

23. Priority matters.
If everything is important, nothing is.

25. Performance, is all about
trade-offs.

26. is the core of the problem we
have to solve [...] legitimately difficult problems.
is all the stuff that doesn’t
necessarily relate directly to the solution, but that we
have to deal with anyway.
Neal Ford, Investigating Architecture and Design (2009)

27. We can have essential and
accidental performance costs,
too.
* And often it can be hard to tell the difference.

28. Know the essential
performance cost of features
you write.

29. Look for opportunities to
remove accidental
performance costs.

30. (function () {
const condition = true;
function fibonacci(x) {
return x <= 1 ? x : fibonacci(x - 1) + fibonacci(x - 2);
}
if (condition === true) {
window.result = fibonacci(23);
} else {
window.result = fibonacci(32);
}
})();

31. (function(){function b(a){return
1>=a?a:b(a-1)+b(a-2)}window.result=b(23)})();
UglifyJS2
https://github.com/mishoo/UglifyJS2
Closure Compiler
https://developers.google.com/closure/compiler

32. result = 28657;
Prepack (experimental only!)
https://prepack.io/

36. Browsers limit the number of
HTTP/1.1 requests made in parallel
from a single hostname.

37. Distribute resource requests across multiple domains, allowing
the browser to parallelize requests

38. Distribute resource requests across multiple domains, allowing
the browser to parallelize requests
… but there’s overhead. New DNS lookup, time to establish
connection.

39. Distribute resource requests across multiple domains, allowing
the browser to parallelize requests
… but there’s overhead. New DNS lookup, time to establish
connection.
General guideline: shard across two domains.

40. But we have a better solution today...

42. H2 can download multiple files in
parallel over a single multiplexed
connection.

44. H2 can download multiple files in
parallel over a single multiplexed
connection.

45. Adopt H2 today
● Ensure resources are served via HTTPS
● If you use a content-delivery network (CDN)
there’s a good chance it supports HTTP/2 today.
● If you’re already domain sharding, make sure
those hostnames resolve to the same IP.

47. Designing APIs is difficult

48. How data is requested between
browser and server can impact
performance.

49. Imagine using the GitHub API to
request the description of a repo.

50. GET repos/octocat/Hello-World
{
"id": 1296269,
"name": "Hello-World",
"full_name": "octocat/Hello-World",
"owner": {},
"private": false,
"html_url": "https://github.com/octocat/Hello-World",
"description": "My first repository on GitHub!",
"fork": false,
"homepage": "",
"size": 578,
"stargazers_count": 1405,
"watchers_count": 1405,
"language": null,
"has_issues": true,
"has_projects": true,
"has_downloads": true,
"has_wiki": true,
"has_pages": false,
"forks_count": 1169,
"mirror_url": null,
"open_issues_count": 251,
"forks": 1169,
"open_issues": 251,
"watchers": 1405,
"default_branch": "master",
"network_count": 1169,
"subscribers_count": 1544
}
{ REST }

51. In a RESTful API, provide
mechanisms to request only the data
needed.

52. Alternative API paradigms might
provide a better format for selecting
only the data needed.

53. repository(owner:"octocat", name:"Hello-World") {
description
}
{
"data": {
"repository": {
"description": "My first repository on GitHub!"
}
}
}

54. GraphQL can help prevent
over-serving data, and reduce the
number of overall requests.

59. How can you avoid re-requesting
data we’ve already downloaded?

62. ● Caching layers on the server
● Single-page application on the client, share data between
routes or components
○ Normalized top-level data
○ Smart client-side caching

64. A lot of performance is about
perception.

68. 70k
https://code.facebook.com/posts/991252547593574/the-technology-behind-preview-photos/
200 bytes

69. There’s no one-size-fits-all method
for improving perceived
performance.
Be creative!

71. “Progressive Web Apps”
● PWAs focus on building web applications that work well in
environments with slow, intermittent, or zero network
connectivity.
● More than just “offline” support, PWA techniques can provide
features of your app even when the network connection is
imperfect.

72. ServiceWorker
● ServiceWorker is browser technology that allows a separate
script to run in the browser background, separate from your
web site, intercept and handle network requests, and
communicate back to your web application.
● You can cache data and other page assets in order to serve
them to your web application even if no external network
connection is available.

74. The browser has a lot to do on a
single thread when rendering a
page...don’t let JavaScript get in the
way.

75. window.requestAnimationFrame()
allows you to schedule something before
the next repaint.

76. But what about non-critical JS...how
do we ensure it doesn’t block more
important work on the main thread?

77. window.requestIdleCallback()
allows you to schedule something when the
browser is idle.

78. window.requestIdleCallback()
allows you to schedule something when the
browser is idle.

80. Request
> router/controller
> request data
> prepare view
> request data
> prepare view
> prepare view
> flush response

81. Why make the user wait for the
whole page to be done?

82. “The general idea is to decompose web pages into small
chunks called pagelets, and pipeline them through
several execution stages inside web servers and
browsers.”
Changhao Jiang, “BigPipe: Pipelining web pages for high performance” (2010)

84. ● Streaming HTML
○ HTML Chunked Encoding
○ ob_flush()
● Client-side powered
○ XHR requests for individual components

85. Request
> router/controller
> request data
> prepare view
> flush response
> request data
> prepare view
> flush response
> prepare view
> flush response

87. Measure performance Reuse data
Load important resources first
Manage perceived
performance
Run less code Anticipate poor connections
Parallelize requests
Don’t try to do everything at
once
Only ask for what you need Send content as it’s ready

92. @AndrewRota