Blog

June 5, 2019

Making Facebook Faster: An Inside Look at the Web Speed Team in NYC

The speed at which a website loads is critical to a positive user experience—especially if you are a company like Facebook.

We connected with the Web Speed Team from Facebook's NYC office to learn more about their mission, how the team is organized, the details of their work, and more.

Are you interested in joining the team? Check out Facebook's job openings on the righthand sidebar of this page.

Can you share the details on the mission behind Facebook’s Web Speed Team in NYC?

The Web Speed team’s mission is focused on making the family of Facebook web products—Facebook, Instagram, WhatsApp, Messenger, Oculus, Workplace—fast and reliable.

Our primary focus this year is on FB5, a fresh new design for Facebook that we recently announced at F8, our annual conference about the future of technology. We’re excited to launch the new design that’s simpler, faster, more immersive and puts your communities at the center.

Making our websites fast is a critical part of our user experience. From the moment you navigate to facebook.com in your browser, we want the experience to feel snappy and responsive. Given a site as feature-rich as Facebook, to meet this goal, we have to push web technology to its absolute limit. In some cases, we work with browser partners to push the web forward with new, cutting-edge features.

Our mission also requires us to be scientific and driven by measurement. By building tools to understand how a website loads—for example, how long different operations take—we can find the right areas to optimize and keep the user experience responsive.

What are the different areas that the Web Speed Team works on as part of Facebook’s Infrastructure group?

The team works in three main areas:

  • Resource Delivery — The team optimizes how Facebook’s servers communicate with desktop browsers to make experiences fast and responsive. Additionally, this team helps our own internal “customers”—product engineers—to think about performance when they are developing new products and applications.

  • Browser Engineering — The team works closely with browsers (such as Google's Chrome and Mozilla's Firefox) as well as the web standards community to make the web better for everyone.

  • Tools and Instrumentation — For internal product engineers, the team creates brand-new UIs to visualize complex datasets, understand where performance is slow and show how it can be improved.

How does this team continue to push the limits of web speed at Facebook scale?

Because of our unique position of working on performance tooling, while having a very deep understanding of how web browsers work, we’re able to uncover novel opportunities for improvements. And not just improvements to our site, but to how web browsers in general can work.

A timely example of this is our work around JavaScript scheduling, recently covered here. We were able to use our deep understanding of website load performance to uncover a bottleneck on the web, and then propose a solution to fix it. This kind of work is especially rewarding since it benefits not only Facebook, but anyone developing on the web platform.

Along those same lines, we’ve used our unique perspective to uncover that parsing JavaScript inside your browser is a large performance bottleneck. To address this, we’re working with Mozilla, Bloomberg and other companies to ship a new format we invented to eliminate the need to parse JavaScript. This new format is called BinAST. This essentially pre-parses JavaScript code, allowing the browser to make dramatic speedups when loading pages. Someone at Cloudflare recently described the project in this article.

These examples just scratch the surface of the many ways in which we’re actively pushing the boundaries of what’s possible on the web.

How are you able to do this on such a wide range of applications, plus factoring in such a wide variety of desktop computers that operate at different levels of processing power?

There’s a large amount of diversity in the types of devices we see across the web and the network conditions those devices run in. In the past, Web developers relied on low-end and slower devices eventually being replaced with newer and more performant hardware. However, desktop hardware trends are evolving, and today, older devices are sticking around for longer periods of time. Also, our team sees people using Facebook’s web products from practically every network condition possible. As a result, a high-end device with flash memory will perform and load a site very different from a low-end device with a spinning disk. The same goes for networks with a good amount of packet loss vs ones without as much packet loss, etc. We deal with this diversity in two ways. First, we do most of our performance measurements in the wild, and we ship experiences tailored to the capabilities of a user’s specific device.

Given how many different experiences Facebook’s web products offer and all the different types of devices that load these experiences, it’s impossible to measure the performance of every single device in a lab setting. Instead, we do most of our performance monitoring based on performance data from the wild. The same goes for performance investigations as well. Since there’s so much diversity in how the site performs in the wild, the best place to look for wins is based on the unique experiences our real users are having on a day-to-day basis.

In a similar vein, we make sure to take this diversity of devices into account when shipping experiences to the web and try to tailor the experience to a person’s specific device. For example, a higher-end device might be able to show a loading animation without impacting the overall user experience. However, displaying the same animation on a lower-end device may end up dramatically slowing down the page load. As a result, we strip out some of the animations on lower-end devices when the page loads in order to speed up the overall page-loading performance.

How is the Web Speed Team working closely with folks at Google Chrome and in the web standards community?

As of 2019, our team directly contributes to Chromium to make the web faster. These changes land in both Chrome, the soon to be released version of Edge, and other Chromium-based browsers. In the past month, we proposed a new API and worked closely with our counterparts at Google Chrome to contribute code for an origin trial. We are excited to share that the Chrome 74 release includes the origin trial for our isInputPending API, which can be used to improve both overall JavaScript execution time and event response times. This origin trial is a first step to improve scheduling JavaScript on the web. We hope to take developer feedback from this trial and use it to make the case for fully shipping the API. You can learn more about Facebook's first major API contribution to Google’s Chrome here.

Are you hiring for this team?  What positions?

Yes! We’re hiring across all three pillars on the Web Speed team:

  • Resource Delivery: We’re looking for strong server-side engineers to keep our backend services performing well.

  • Browser Engineering: We’re looking for strong C++ skills, expertise with web APIs, and ideally Android experience for mobile browser work.

  • Tools & Instrumentation: Using React and Relay, we build UIs for our own engineers to visualize performance data and diagnose problems.

What types of backgrounds do you generally look for?

A strong background in algorithms definitely helps, given the scale at which we operate. Success on our team is often associated with a passion for optimizing things and making them faster; being comfortable working with large datasets, and working well with ambiguity to look for new insights.


Keith Cline is the Founder of VentureFizz. Follow him on Twitter: @kcline6.

Our current openings

92 Job Openings