March 5th, 2018
Issued by: Mozilla
Mozilla Representative: Kadir Topal, firstname.lastname@example.org, Product Manager for MDN
Introduction and Background
MDN Web Docs (developer.mozilla.org) is a website containing technical documentation that provides web developers with the information they need to build things on the web platform. MDN is in need of a performance audit and is accepting proposals in response to this Request for Proposal in order to find a qualified source to provide that audit.
MDN aligns with Mozilla’s mission, but also helps Mozilla maintain a position of leadership on the web platform. MDN’s KPI (Key Performance Indicator) is the volume of successful sessions that come to MDN. This is the product of our site wide task completion rate and article view sessions [Task Completion Rate] x [Article view sessions]. Currently, MDN has a task completion rate >80% meaning that growth in successful sessions will largely need to come from an increase in site sessions.
At present, we help solve in excess of 14M developer issues per month across over 16M site sessions per month with 75% of traffic from organic search. These engagements with developers are typified by the following characteristics:
- Developers enter on a long tail of pages (the top 10 landing pages account for only 7% of total traffic)
- Their visits are typically limited to one pageview per visit (either it solves their need or it doesn’t but no site engagement is necessarily required)
Project Goal and Target Audience
Page load performance is an important factor for user engagement and SERP ranking. We know that we haven’t exhausted all options to optimize MDN for page load performance yet, we’d like to know whether there are opportunities that are worth going after and if yes, in what order. The ultimate goal is to increase successful sessions on MDN through improved page load performance for new and repeat visitors.
Our goal with the MDN performance audit is to:
- Understand what our options are in order to improve page load performance on MDN
- Understand the cost and impact of those options
- Set MDN up to act on those options
MDN’s audience consists of web developers and others who build things on the web. Currently the top countries are the US, India, China, France, Germany, Japan. China is showing a lot of growth, and we’d like to support that. MDN is multilingual, with English as the dominant language, but there is significant traffic to Chinese, French and Spanish content. All in all, more than 40 languages are supported on MDN.
Sites with a similar audience
- MDN is a Django based web site
- Currently hosted in AWS
- Details in: https://github.com/mozilla/kuma
Scope of work and deliverables
- Define MDN performance KPI and diagnostic metrics
- Create reporting that monitors performance
- Conduct and summarize a performance audit of MDN
- Generate a list of prioritized recommendations to improve MDN performance
- In cooperation with developers: recommendations broken down into user stories that fit into our sprint based workflow
- Presentation of final recommendations and expected impact
- Weekly status meetings
- Project management
Next Steps After the Engagement
After this engagement, we should be able to do the following:
- Plan projects that address performance in Q3
- Decide what opportunity to address next
- See impact of addressed opportunity in the performance report
Ongoing Support / Retainer
- 10 hours past the final presentation
Principal point of contact
- Contract and product lead: Kadir Topal
- Project Management: Janet Swisher
- Development lead: John Whitlock
Submission Guidelines & Requirements
- First and foremost, only qualified individuals or firms with prior experience on projects such as this should submit proposals in response to this Request for Proposal.
- Bidders intent on submitting a proposal should so notify the representative identified on the cover page no later than March 25th, 2018.
- Bidders must list at least 2 projects that are substantially similar to this project as part of their response, including references for each. Examples of work should be provided as well.
- A technical proposal must be provided. This technical proposal must provide an overview of the proposed solution as well as resumes of all key personnel performing the work. In addition, the technical proposal should provide a proposed schedule and milestones, as applicable.
- A price proposal must be provided. This price proposal should indicate the overall fixed price for the project as well as hourly rates and an estimated total number of hours, should Mozilla decide to award a contract on an hourly rate basis.
- Proposals must be signed by a representative that is authorized to commit bidder’s company.
- If you have a standard set of terms and conditions, please submit them with your proposal. All terms and conditions will be subject to negotiation.
- Proposals must be received prior to March 30th, 2018 to be considered.
- Proposals must remain valid for a period of 30 days.
- Mozilla anticipates selecting at least two individuals or firms to have more in-depth discussions with, and will make an award to one of these “down-selected” individuals or firms.
RFP & Project Timelines
The Request for Proposal timeline is as follows:
Request for Proposal Issuance
March 5th, 2018
Selection of Top Bidders / Notification to Unsuccessful Bidders
April 2nd, 2018
Start of Negotiation
April 9th, 2018
Contract Award / Notification to Unsuccessful Bidders
April 16th, 2018
The need-date for project completion is June 15th, 2018. Bidders may propose a date earlier or later, and will be evaluated accordingly.
Mozilla will rate proposals based on the following factors:
- Responsiveness to the requirements set forth in this Request for Proposal
- Relevant past performance/experience
- Samples of work
- Cost, including an assessment of total cost of ownership
- Technical expertise/experience of bidder and bidder’s staff
Mozilla reserves the right to award to the bidder that presents the best value to Mozilla as determined solely by Mozilla in its absolute discretion
It has been Mozilla’s experience that a Request for Proposal and subsequent proposal response represent an early stage in the contracting process. Typically, the RFP and response proposals are not drafted in legal language that clearly defines the obligations and rights of the parties. However, Mozilla regards any bidder proposal submitted in response to this RFP as a commitment to “business terms” that Mozilla might reasonably rely upon as the basis for developing a definitive written agreement between Mozilla and the bidder. Mozilla’s normal practice is to mutually negotiate a definitive written agreement, which incorporates legal terms with these business terms. The definitive agreement will include specific, objective details with respect to the rights and obligations of the parties, including such issues as warranty, financial responsibilities, deliverables, maintenance, confidentiality and protection of Mozilla’s proprietary rights and data.
The material and information enclosed with this RFP are based on current Mozilla requirements, and may change. The information in this RFP does not represent an offer or commitment by Mozilla to procure services. Mozilla reserves the right to modify or withdraw its requirements as expressed herein. Neither Mozilla nor any bidder responding to this RFP shall be considered to have entered into a binding agreement regarding the acquisition or provision of equipment, software, and / or services described herein, until and unless the authorized representative of both parties has signed a separate final definitive agreement regarding such equipment, software or services.