How to make a chart of your users' window sizes

In preparation for the MDN redesign I examined our analytics to get an idea of how wide our users’ browser windows were. I wanted window widths, not screen sizes and I thought a chart would tell a more compelling story than a table.

Here’s the chart I made:

Chart of MDN window widths showing spikes at 1350 and 1900 pixels and very
little between 420 and 930 pixels.

I found this view useful because it shows us “clumps” of window sizes.

How to make a chart of browser window widths

The basic idea is:

  1. Create and export a Custom Report for Browser Size.
  2. Filter the Browser Size to just include widths.
  3. Aggregate the number of users for each width.
  4. Make a chart.

Working with Google Analytics and Google Sheets the specific steps I used were:

  1. Create a custom report for browser sizes.
    1. Customization > Custom Reports > New Custom Report
    2. Set the Metric Group to Users
    3. Set Dimension Drilldowns to Browser Size
    4. Save
  2. View the custom report.
  3. Set Show rows: to 5000.
  4. Export to Google Sheets.
  5. Delete the extra stuff from the top and bottom of the export, you just want two columns: Browser Size, and Users.
  6. Create a new column (C) called Width. Add this regex to it and fill down: =REGEXEXTRACT(A2, "^[0-9]+"). This gives you a column with just the width part of the browser size.
  7. Create a new column (D) called Unique List. Add this formula to it (you don’t need to fill down): =UNIQUE(C2:C5001).This gives you a list of widths with no repeating values. That means 1900x950 and 1900x970 will be treated the same in our final chart.
  8. Create a new column (E) called Conditional Sums. Add this formula and fill down the height of your Unique List: =SUMIF(C$2:C$5001,D2,B$2:B$5000).
  9. Copy the Unique List and Conditional Sums columns.
  10. Create a new sheet in your document.
  11. Use Edit > Paste special > Paste values only to paste only the computed values of these columns.
  12. Rename Unique List to Width and Conditional Sums to Total Users.
  13. Find the (not set) row and delete it.
  14. Make sure both columns are being treated as numbers (a hint this is happening properly is that they are right aligned). If you have headings on the columns make sure they’re frozen (View > Freeze > 1 row).
  15. Sort on Width from A→Z.
  16. Select both columns and create a chart (Insert > Chart). (I made a “Stepped area chart”)
  17. Set Width as the X-axis.
  18. Done!

This answered a question I’ve been curious about for ages: Do people with large monitors use MDN full screen? About 40% of our users have a screen resolution of 1900px or wider and 25% of our users use MDN at 1900px or wider.

MozMEAO SRE Status Report - January 23, 2018

Here’s what happened on the MozMEAO SRE team from December 2017 - January 23.

Current work

SRE general

We’re busy setting up multiple Kubernetes 1.8 clusters in us-west-2 to serve SUMO, Bedrock and other MozMEAO applications. These new clusters will replace our Deis 1 cluster in the same region.

The Bedrock team will be moving from an RDS database to updates distributed via S3. This will make Bedrock hosting cheaper and easier to manage.

Additionally, Bedrock needs to be tweaked to run on Kubernetes natively as Deis Workflow is being discontinued.


MDN is switching it’s Celery results backend from MySQL to Redis, to avoid database reads/writes. No significant difference in throughput noticed. (SUMO)

Work is progressing quickly on the SUMO move from SCL3 to AWS.

User media is now hosted by S3 and Cloudfront in SCL3 as of 2017-01-17 14:14 UTC. This makes our migration easier as it’s one less component we have to plan for on go-live day.

We’ve been discussing SUMO database architecture with a focus on high uptime. We’re also discussing our Elasticsearch architecture.

Work on a new CDN is in-progress for hosting static media in AWS. We’ll need to request a few DNS changes and certificates in order to proceed.

The team is also working on establishing MySQL replication between SCL3 and RDS, in order to significantly decrease the deployment window on migration day.

Kuma Report, December 2017

Here’s what happened in December in Kuma, the engine of MDN Web Docs:

Here’s the plan for January:

Done in December

Purged 162 KumaScript Macros

We moved the KumaScript macros to GitHub in November 2016, and added a new macro dashboard. This gave us a clearer view of macros across MDN, and highlighted that there were still many macros that were unused or lightly used. Reducing the total macro count is important as we change the way we localize the output and add automated tests to prevent bugs.

We scheduled some time to remove these old macros at our Austin work week, when multiple people could quickly double-check macro usage and merge the 86 Macro Massacre pull requests. Thanks to Florian Scholz, Ryan Johnson, and wbamberg, we’ve removed 162 old macros, or 25% of the total at the start of the month.


Increased Availability of MDN

We made some additional changes to keep MDN available and to reduce alerts. Josh Mize added rate limiting to several public endpoints, including the homepage and wiki documents (PR 4591). The limits should be high enough for all regular visitors, and only high-traffic scrapers should be blocked.

I adjusted our liveness tests, but kept the database query for now (PR 4579). We added new thresholds for liveness and readiness in November, and these appear to be working well.

We continue to get alerts about MDN during high-traffic spikes. We’ll continue to work on availability in 2018.

Improved Kuma Deployments

Ryan Johnson worked to make our Jenkins-based tests more reliable. For example, Jenkins now confirms that MySQL is ready before running tests that use the database (PR 4581). This helped find an issue with the database being reused, and we’re doing a better job of cleaning up after tests (PR 4599).

Ryan continued developing branch-based deployments, making them more reliable (PR 4587) and expanding to production deployments (PR 4588). We can now deploy to staging and production by merging to stage-push and prod-push for Kuma as well as KumaScript, and we can monitor the deployment with bot notifications in #mdndev. This makes pushes easier and more reliable, and gets us closer to an automated deployment pipeline.

Added Browser Compatibility Data

Daniel D. Beck continued to convert CSS compatibility data from the wiki to the repository, and wrote 35 of the 57 PRs merged in December. Thanks to Daniel for doing the conversion work, and thanks to Jean-Yves Perrier for many reviews and merges over the holiday break.

Stephanie Hobson continued to refine the design of the new compatibility tables, including an icon for the Samsung Internet Browser and an updated Firefox icon (Kuma PR 4605). Florian Scholz added a legend, to explain the notation (KumaScript PR 437). We’re getting closer to shipping these to all users. Please give any feedback at Beta Testing New Compatibility Table on Discourse.

Said Goodbye to Stephanie Hobson

Stephanie Hobson is moving to the bedrock team in January, where she’ll help maintain and improve Schalk Neethling will take over as the primary front-end developer for MDN Web Docs.

Over the past 3½ years, Stephanie has had a huge impact on MDN. She shared her expertise on accessibility, multi-language support, readable HTML tables and all things Google Analytics. She advocated for the users during the spam mitigations and Persona shutdown. She’d argue for design changes from a web developer’s perspective, and back it up with surveys and interviews.

She’s also a talented developer, authoring over 400 PRs. She’s responsible for a lot of the changes on MDN in 2017:


Schalk has been working on MDN for most of 2017. He’s been focused on the interactive examples project that fully shipped in December. He’s also been reviewing front-end PRs, and his feedback and suggestion have improved the front-end code for months. In December, Stephanie and Schalk worked closely to make a smooth transition, which included getting all the JavaScript to pass eslint tests (PR 4596 and PR 4597).

We look forward to seeing what Stephanie will do on bedrock, and we look forward to Schalk’s work and fresh perspective on MDN Web Docs.

Shipped Tweaks and Fixes

There were 209 PRs merged in December (which was supposed to be a light month):

Several of these were from first-time contributors:

Other significant PRs:

Planned for January

We’re contining on existing projects like BCD in January, and starting some larger projects that will start to ship in February.

Prepare for a CDN

We’ve exhausted the easy solutions for increasing availability on MDN. We believe the next step is to put behind a Content Distribution Network, or CDN. Once we have everything setup, most requests won’t even hit the Kuma engine, but instead will be handled by caching servers around the world. We expect it to take 1 - 2 months before we can get the majority of requests served by the CDN.

A first step is to reduce the page variants sent to anonymous users, so that the CDN edge servers can handle most requests. Schalk Neethling has been removing waffle flags or migrating them to switches over many PRs, such as PR 4561.

In January, Ryan Johnson will start adding the caching headers needed for the CDN to store and serve the pages without contacting Kuma.

We believe a CDN will reduce downtime and alerts from increased traffic. More importantly, we expect it will speed up MDN Web Docs for visitors outside the US.

Ship More Interactive Examples

We launched the interactive example editor on a dozen pilot pages, and the analytics look good. Just before the holiday break, we decided we can ship the interactive example editor to any MDN page. You can see it on CSS background-size, Javascript Array.slice(), and more.

background-size array-slice

We have many more interactive examples ready to publish, including many JavaScript examples by Mark Boas. We’ll roll these and more out to MDN. We’ll also start on HTML interactive examples, and we’re planning to ship them in February. Follow mdn/interactive-examples to see the progress and learn how to help.

Update Django to 1.11

MDN Web Docs is built on top of Django. We’re currently using Django 1.8, first released in 2015. It is a Long-Term Release (LTS) that will be supported with security updates until at least April 2018. Django 1.11, released in 2017, is the new LTS release, and will be supported until at least April 2020. In January, we’ll focus on updating our code and third-party libraries so that we can quickly make the transition to 1.11.

For now, our plan is to stay on Django 1.11 until April 2019, when Django 2.2, the next LTS release, is shipped. Django 2 requires Python 3, and it may take a lot of effort to update Kuma and switch to third-party libraries that support Python 3. We’ll make a lot of progress during the 1.11 transition, and we’ll monitor our Django 2 and Python 3 compatibility in 2018.

Plan for 2018

We have a lot of things we have to do in Q1 2018, such as the CDN and Django 1.11 update. We postponed a detailed plan for 2018, and instead will spend some of Q1 discussing goals and priorities. During our discussions in December, a few themes came up.

For the MDN Web Docs product, the 2018 theme is Reach. We want to reach more web developers with MDN Web Docs data, and earn a key place in developers’ workflows. Sometimes this means making the best place to find the information, and sometimes it means delivering the data where the developer works. We’re using interviews and surveys to learn more and design the best experience for web developers.

For the technology side, the 2018 theme is Simplicity. There are many seldom-used Kuma features that require a history lesson to explain. These make it more complicated to maintain and improve the web site. We’d like to retire some of these features, simplify others, and make it easier to work on the code and data. We have ideas around zone redirects, asset pipelines, and translations, and we hope to implement these in 2018.

One thing that has gotten more complex in 2017 is code contribution. We’re implementing new features like browser-compat-data and interactive-examples as their own projects. Kuma is usually not the best place to contribute, and it can be challenging to discover where to contribute. We’re thinking through ways to improve this in 2018, and to steer contributor’s effort and enthusiasm where it will have the biggest impact.

MozMEAO SRE Status Report - December 5, 2017

Here’s what happened on the MozMEAO SRE team from November 14th - December 5th.

Current work


Work continues on the SUMO move to AWS. We’ve provisioned a small RDS MySQL instance in AWS for development and tried importing a production snapshot. The import took 30 hours on a db.t2.small instance, so we experimented with temporarily scaling the RDS instance to a an db.m4.xlarge. The import is now expected to complete in 5 hours.

We will investigate if incremental backup/restore is an option for the production transition.


MDN had several short downtime events in November, caused by heavy load due to scraping. Our K8s liveness and readiness probes often forced pods to restart when MySQL was slow to respond.

Several readiness and liveness probe changes were issued by @escattone and @jwhitlock to help alleviate the issue:

The November 2017 Kuma report has additional details.

We now have a few load balancer infrastructure tests for MDN, implemented in this pull request.

MDN Interactive-examples

Caching is now more granular due to setting different cache times for different assets.


Bedrock is transitioning to a local Sqlite DB and clock process in every container. This removes the dependency on RDS and makes running Bedrock cheaper. In preparation for this change, S3 buckets have been created for dev, stage and prod.

Kuma Report, November 2017

Here’s what happened in November in Kuma, the engine of MDN Web Docs:

We’re planning on more of the same for December.

Done in November

Shipped the First Interactive Examples

We’ve launched the new interactive examples on 20+ pages. Try them out on the pages for the CSS property box-shadow and the JavaScript method Array.slice.

box-shadow example

We’re monitoring the page load impact of this limited rollout, and if the results are good, we have another 400 examples ready to go, thanks to Mark Boas and others. Mark also added a JavaScript Interactive Examples Contributing Guide, so that contributors can create even more.

We want the examples to be as fast as possible. Schalk Neethling improved the page load speed of the <iframe> by using preload URLs (PR 4537). Stephanie Hobson and Schalk dived into HTTP/2, and identified require.js as a potential issue for this protocol (Kuma PR 4521 and Interactive Examples PR 329). Josh Mize added appropriate caching headers for the examples and static assets (PR 326).

For the next level of speed gains, we’ll need to speed up the MDN pages themselves. One possibility is to serve from a CDN, which will require big changes to make pages more cacheable. One issue is waffle flags, which allow us to experiment with per-user changes, at the cost of making pages uncacheable. Schalk has made steady progress in eliminating inactive waffle flag experiments, and this work will continue into December.

Continued Migration of Browser Compatibility Data

The Browser Compatibility Data project was the most active MDN project in November. 36.6% of the MDN pages (2284 total) have been converted. Here are some highlights:

  1. Imported more CSS data, such as the huge list of allowed values for the list-style-type property (this list uses georgian). This property alone required 7 PRs, starting with PR 576. Daniel D. Beck submitted 32 CSS PRs that were merged in November, and is making good progress on converting CSS data.
  2. Added browser and version validation, a month-long effort in PR 439 from Florian Scholz and Jean-Yves Perrier.
  3. Added a runtime_flag for features that can be enabled at browser startup (PR 615 from Florian Scholz).
  4. Add the first compatibility data for Samsung Internet for Android (PR 657 from first-time contributor Peter O'Shaughnessy).
  5. Shipped the new compatibility table to beta users. Stephanie Hobson resurrected a design that had been through a few rounds of user testing (PR 4436), and has made further improvements such as augmenting colors with gradients (PR 4511). For more details and to give us feedback, see Beta Testing New Compatability Tables on Discourse.

New Browser Compatibiility Table

Sticky Table of Contents and Other Article Improvements

We shipped some additional article improvements in November.

The new table of contents is limited to the top-level headings, and “sticks” to the top of the window at desktop sizes, showing where you are in a document and allowing fast navigation (PR 4510 from Stephanie Hobson).

Sticky Table of Contents

The breadcrumbs (showing where you are in the page hierarchy) have moved to the sidebar, and now has metadata tags. Stephanie also refreshed the style of the sidebar links.

Breadcrumbs and Quick Links

Stephanie also updated the visual hierarchy of article headings. This is most noticeable on <h3> elements, which are now indented with black space.

New <h3> style

Improved MDN in AWS and Kubernetes

We continued to have performance and uptime issues in AWS in November. We’re prioritizing fixing these issues, and we’re delaying some 2017 plans, such as improving KumaScript translations and upgrading Django, to next year.

We lost GZip compression in the move to AWS. Ryan Johnson added it back in PR 4522. This reduced the average page download time by 71% (0.57s to 0.16s), and contributed to a 6% decrease in page load time (4.2 to 4.0s).

Page Download drop due to GZip

Heavy load due to scraping caused 6 downtimes totaling 35 minutes. We worked to improve the performance of unpopular pages that get high traffic from scrapers, such as document list views (PR 4463 from John Whitlock) and the revisions dashboard (PR 4520 from Josh Mize). This made the system more resilient.

Kubernetes was contributing to the downtimes, by restarting web servers when they started to undergo heavy load and were slow to respond. We’ve adjusted our “readiness” and “liveness” probes so that Kubernetes will be more patient and more gentle (Infra PR 665 from Ryan Johnson).

These changes have made MDN more resilient and reliable, but more work will be needed in December.

Stephanie Hobson fixed the development favicon appearing in production (PR 4530), as well as an issue with lazy-loading web fonts (PR 4533).

Ryan Johnson continues work on our deployment process. Pushing certain branches will cause Jenkins to take specific deployment steps. Pushing master will run tests and publish a Docker image. Pushing stage-push will deploy that image to Pushing stage-integration-tests will run browser and HTTP tests against that deployment. We’ll make these steps more reliable, add production variants, and then link them together into automated deployment pipelines.

Shipped Tweaks and Fixes

There were 260 PRs merged in November:

Many of these were from external contributors, including several first-time contributions. Here are some of the highlights:

Planned for December

Mozilla gathers for the All-Hands event in Austin, TX in December, which gives us a chance to get together, celebrate the year’s accomplishments, and plan for 2018. Mozilla offices will shut down for the last full week of December. This doesn’t leave a lot of time for coding.

We’ll continue working on the projects we worked on in November. We’ll convert more Browser Compatibility data. We’ll tweak the AWS infrastructure. We’ll eliminate and convert more waffle flags. We’ll watch the interactive examples and improved compatibility tables, and ship them when ready.

We’ll also take a step back, and ask if we’re spending time and attention on the most important things. We’ll think about our processes, and how they could better support our priorities.

But mostly, we’ll try not to mess things up, so that we can enjoy the holidays with friends and family, and come back refreshed for 2018.