PageSpeed represents a series of open source technologies to help make the web faster by rewriting web pages to reduce latency and bandwidth.
PageSpeed is an open source library that can be embedded in a web server or proxy server to perform just-in-time optimization of its output. PageSpeed has two stable open source implementations: mod_pagespeed (httpd), ngx_pagespeed (nginx). There is also ats_pagespeed (experimental), and there are proprietary implementations (Microsoft IIS, OpenLiteSpeed, and others).
This proposal assumes a single project for the pagespeed library and its three derived open source implementations:
Studies indicate that there is a negative correlation between slow site speeds and important business metrics, like conversion, retention, and others. Web performance optimization is a fast moving target, and it is both hard and expensive for companies to keep up with the current state of technology. PageSpeed optimization represents an opportunity for website owners to deliver content up to date with the latest web performance best practices at reduced costs, without changing development workflows.
We think that the ASF offers the ideal environment to foster and grow the project’s community. Many organizations can benefit from automatic web optimization.
The initial goals of the pagespeed project are several-fold:
- Foster and grow the community
- Move the existing codebases to Apache and integrate with the Apache development process.
- Move the docs into a separate repository, so we can (more easily) decouple product releases from documentation updates. (Ideally the process for making small doc changes is a low friction one).
- Finish and land content-security-policy support
- Finish and land changes in PageSpeed’s resource fetching infrastructure (including a change that teaches it about following redirects).
- Add Alpine Linux to the list of supported distributions due to popular demand.
- Turn the experimental central controller process on by default. Having a central controller process is useful when someone wants to implement:
- Centrally fetching input resources
- Running phantomjs centrally for implementing more advanced optimization opportunities
- Optimizing the file cache cleaning system
- More efficient handling of compute intensive optimizations (like image transcoding and (re-)compression)
- If we do all of the above, a lot of the project’s dependencies would end up running in a separate process. That offers further advantages from a security perspective.
With the changes above, we propose releasing a 2.0 version of mod_pagespeed!
Next up would be allowing for intelligent decisions based on protocol (http/2, quic). (ngx_pagespeed already is capable of doing this (and more) to some extent with its script variable support.)
Google launched mod_pagespeed in 2010 to provide free open-source technology to automate deployment of best practices for web front end delivery. Since that time, the module has gained broad adoption, with hundreds of thousands of installs including 1.2% of the top 10k sites. The PageSpeed Optimization Libraries have been used in products such as the Chrome Data Reduction proxy, PageSpeed Insights, Accelerated Mobile Pages (AMP), and Google Web Light, as well as a plethora of CDN/Hosting/Plugin channels to help any website deploy PageSpeed, including Verizon/Edgecast’s CDN, we-amp’s IIS WebSpeed and ats_pagespeed, SiteGround, Section.IO, OpenLitespeed, and cpanel.
We plan to invest in supporting a meritocracy. We will discuss the requirements in an open forum. The project is used by a huge amount of companies, and we intend to invite additional developers to participate. We will encourage and monitor community participation so that privileges can be extended to those that contribute.
The need for a platform capable of automatically optimizing web content in the open source community has turned out tremendous. We are hoping that embracing “the Apache way” will accelerate the growth of our community. We have already been active at seeking and inviting contributions.
The initial committers for pagespeed include experienced engineers:
- Otto van der Schaaf - (We-Amp / IISWebSpeed)
- Kees Spoelstra - (We-Amp / IISWebSpeed)
- Ashish Kulkarni - (We-Amp / IISWebSpeed)
- Joshua Marantz - (Google)
- Maksim Orlovich - (Google)
We realize that additional employer diversity is needed, and we will work to recruit developers from additional companies.
The initial committers strongly believe that a system for optimizing web content will gain broader adoption as an open source, community driven project.
Google has recently stepped down as the controlling entity of the project. Individual committers from Google are still involved in the project along with continued involvement from We-Amp. We plan to mitigate the risks of this transition by recruiting additional committers. We expect the ASF to be a good environment for growing our community.
Inexperience with Open Source
The initial committers include Apache members (committers and PPMC members) and developers who have varying degrees of experience with open source projects. All have been involved with source code that has been released under an open source license, and several also have experience developing code with an open source development process.
The initial committers are employed by We-Amp B.V. and Google Inc. We are committed to recruiting additional committers from other companies.
Reliance on Salaried Developers
It is expected that PageSpeed development will occur on both salaried time and on volunteer time, after hours (or 20% time). We-Amp’s committers are paid by their company (IIS WebSpeed) to contribute to this project. However, all involved are very passionate about the project, and we are confident that the project will continue even if no salaried developers contribute to the project. We are committed to recruiting additional committers including non-salaried developers.
Relationships with Other Apache Products
To the knowledge of the Initial Committers, there are no direct competitors to pagespeed optimization within the Apache Software Foundation. The project implements modules for both Apache httpd and Apache Traffic Server. We look forward to collaborating with those communities, as well as other Apache communities.
An Excessive Fascination with the Apache Brand
Our rationale for developing pagespeed optimization as an Apache project is detailed in the Rationale Section. We believe that the Apache brand and community process will help us attract more contributors to this project, and help grow the footprint of the project through usage at other organizations and within other applications. Establishing consensus among users and developers will result in a more valuable product for everyone.
References to further reading material:
The origin of the proposed code base can be found at https://github.com/pagespeed/. The code base is primarily in C/C++ (Google C++ Style).
Source and Intellectual Property Submission Plan
Google will submit a Software Grant Agreement (SGA) as mod_pagespeed and ngx_pagespeed join the incubator. We do not expect any complications for the submission of these code bases, which are already on Github and Apache licensed. ats_pagespeed already has been submitted.
List of external dependancies: third party deps. We believe most of these dependencies meet all Apache policies, and will conduct a more thorough review during incubation.
The proposal does not include cryptographic code. The project depends on BoringSSL, but does not include it.
Currently continuous integration is performed at travis. There is also ci.onpagespeed.com sponsored by IIS WebSpeed which performs more extensive tests on commits to mod_pagespeed and ngx_pagespeed.
Currently there are mailing lists hosted on Google Groups, that we can deprecate as the Apache.org become ready to serve our community.
Git is the preferred source control system.
Git is the preferred source control system (We are proposing https://github.com/apache/incubator-pagespeed based on the naming scheme)
JIRA pagespeed (pagespeed). If possible, we’d like to use Github issues & PRs to manage our project as much as possible. It’s been said that there are ways to keep Github’s issues in sync with Jira, allowing us to get best of both worlds. If that is not possible, we will comply to using Jira.
We currently use a set of Github integrated services that are free to the open source community, like Travis-ci. We would like to keep using these services as they allow us to scale contributions and optimize our development flows. These services require some elevated rights on the Github repository in order to set up or tune and we would like for the committers to have the required rights.
- Joshua Marantz <email@example.com> (Google) - committer
- Maksim Orlovich <firstname.lastname@example.org> (Google) - committer
- Otto van der Schaaf <email@example.com> (We-Amp) - committer
- Kees Spoelstra <firstname.lastname@example.org> (We-Amp) - committer
- Ashish Kulkarni <email@example.com> (We-Amp) - committer
- Leif Hedstrom <firstname.lastname@example.org> - Champion, mentor and committer
- Jukka Zitting <email@example.com> - Mentor
- Nick Kew <firstname.lastname@example.org> - Mentor
- Phil Sorber <email@example.com> - Mentor
The initial committers are employees of Google Inc., We-Amp B.V.
- Google, We-Amp / IIS WebSpeed
- Leif Hedstrom <firstname.lastname@example.org>
- Jukka Zitting <email@example.com>
- Leif Hedstrom <firstname.lastname@example.org>
- Nick Kew <email@example.com>
- Phil Sorber <firstname.lastname@example.org>