nyuuzyou/wikis huggingface dataset:
Performance/FOSDEM 2020 Call for Participation

FOSDEM 2020 Call for Participation: Web Performance
FOSDEM is a Free Software event that offers free software communities a place to meet, share ideas and collaborate. It brings together 8000+ participants from all over the world. It is held in Brussels (Belgium). FOSDEM will take place during the weekend of February 1st-2nd 2020.
More details about the event can be found at https://fosdem.org/.
You can watch the talks at https://performance.wikimedia.org/fosdem20webperf/
== Web Performance devroom ==
The Web Performance devroom will focus on ongoing open standards development and FLOSS projects that support Web Performance work.
The Web Performance field is driven by open standards (browser APIs, internet protocols) and relies on many FLOSS tools to monitor, analyse and improve performance.
Most conferences about this topic tend to focus on best practices and standards once they’ve been finalized, while the ongoing creation of standards and FLOSS tooling development is rarely talked about. The objective of this devroom is to bring focus to these critical areas that actually define the future of the Web Performance field.
Suggested presentation topics:
* FLOSS tools to monitor, measure, analyse, optimize backend or frontend web performance
* Open standards (eg. HTTP/3, upcoming JS/HTML/CSS standards)
* Academic research on web performance
== Submission process ==
The talk length should be 30 minutes + 5 minutes for Q&A. If you need a different talk length, please provide a justification in your proposal.
Please submit your proposals at https://penta.fosdem.org/submission/FOSDEM20 before December 2nd 2019.
Click on "Create event" and then on "Show all" in the top right corner to display the full form. Make sure that you select "Web Performance devroom" in the "track" drop-down menu.
Your submission must include the following information:
* The title and subtitle of your talk (please be descriptive, as titles will be listed with hundreds from other projects)
* A short abstract of one paragraph
* A longer description if you wish to do so
* Links to related websites/blogs etc.
== Important dates ==
* December 2nd 2019 deadline for submission of proposals
* December 9th 2019 or before announcement of selected speakers
* December 15th 2019 final schedule is announced
* February 1st-2nd 2020 FOSDEM20!
== Recordings ==
The FOSDEM organizers hope to be able to live-stream and record all the talks. The recordings will be published under the same license as all FOSDEM content (CC-BY). Only presentations will be recorded, not informal discussions and whatever happens during breaks between presentations. By agreeing to present at FOSDEM, you automatically give permission to be recorded. The organizers will agree to make exceptions but only for exceptional and well-reasoned cases.
FOSDEM
Performance/FOSDEM 2021 Call for Participation

FOSDEM 2021 Call for Participation: Web Performance
FOSDEM is a Free Software event that offers free software communities a place to meet, share ideas and collaborate. This year the event will not take place in a physical location but online.
* The reference time will be Brussels local lime (CET).
* Talks will be pre-recorded in advance, and streamed during the event.
* Q/A session will happen live
* Functionality will be provided for people watching to chat between themselves
* Functionality will be provided for people watching to submit questions
More details about the event can be found at https://archive.fosdem.org/2021/schedule/track/web_performance/.
== Web Performance devroom ==
The Web Performance devroom will focus on ongoing open standards development and FLOSS projects that support Web Performance work.
The Web Performance field is driven by open standards (browser APIs, internet protocols) and relies on many FLOSS tools to monitor, analyse and improve performance.
Most conferences about this topic tend to focus on best practices and standards once they’ve been finalized, while the ongoing creation of standards and FLOSS tooling development is rarely talked about. The objective of this devroom is to bring focus to these critical areas that actually define the future of the Web Performance field.
Suggested presentation topics:
* FLOSS tools to monitor, measure, analyse, optimize backend or frontend web performance
* Open standards (eg. HTTP/3, upcoming JS/HTML/CSS standards)
* Academic research on web performance
== Submission process ==
Please submit your proposals using this form before 23 December 2020.
== Important dates ==
* December 16 2020 deadline for submitting talk proposals
* December 23 2020 extended deadline for submitting talk proposals
* January 15 2020 deadline for uploading pre-recorded talks
* Conference dates 6 & 7 February 2021 online
* Sunday February 7th 2021 Web Performance devroom at FOSDEM21 online!
FOSDEM
Performance/FOSDEM 2024 Call for Participation

FOSDEM 2024 Call for Participation: Web Performance
We are excited to announce that the Web Performance devroom will be returning for FOSDEM 2024! This time the room is a joint effort of Mozilla and Wikimedia Foundation.
FOSDEM is the largest Free and Open Source Software event in Europe. It offers free software communities a place to meet, share ideas and collaborate. FOSDEM 2024 will take place on February 3-4th 2024 in Brussels, Belgium. You can learn more at https://fosdem.org/2024/.
=== Web Performance devroom ===
The web performance devroom will focus on ongoing open standards development and FLOSS projects that support performance of the world wide web. The web performance field is driven by open standards (browser APIs, internet protocols), and relies on many FLOSS tools to monitor, analyze and improve performance.
Most conferences about this topic tend to focus on best practices and standards once they’ve been finalized, while the ongoing creation of standards and FLOSS tooling development is rarely talked about. The objective of this devroom is to bring focus to the future of web performance through open standards, and open source developer tools.
Here’s some topic suggestions:
* FLOSS tools to monitor, measure, analyze, optimize backend or frontend web performance
* Open standards (eg. HTTP/3, upcoming JS/HTML/CSS standards)
* Academic research on web performance
* Share your web performance story: Share your challenges and your solutions and what you learned 
* Ethical web performance: Address the balance between performance optimization and user privacy, especially in the context of increasing concerns about data collection practices by large corporations.
=== Submission process ===
Please submit your talk proposal by December 1st. We will let you know if your call has been accepted by December 15th.
All talks will be in person, and can be 15 to 45 minutes in duration (including Q&A).
You can submit your talk proposal at https://fosdem.org/submit making sure to select Web Performance as the track.
Performance/Frontend web performance training

== Context ==
The Performance Team commissioned Jean-Pierre Vincent in 2020 and 2021 to provide remote training on the topic of Frontend Web Performance.
== Format ==
The training is delivered remotely via Zoom, every week day over the course of a week, for a total of 5 sessions lasting 3.5 hours each.
The training is not recorded.
== Alumni ==
The following current or former staff members have undergone this training:
Thalia Chan, Jan Drewniak, Željko Filipin, Samuel Guebo, Alex Hollender, Michael Holloway, Wolfgang Kandek, Roan Kattouw, Dayllan Maza, Harumi Monroy, Stephen Niedzielski, Linh Nguyen, Mew Ophaswongse, Abijeet Patro, Samuel Patton, Gabriel Pita, Nicholas Ray, Sam Reed, Jon Robson, Ed Sanders, Mateus Santos, Joseph Seddon, Aaron Schulz, Bernd Sitzmann, Sam Smith, Huei Tan, Stephanie Tran, Anne Tomasevich, Brion Vibber, Leila Zia.
== Content ==
Here is an approximate skeleton of the training:
==== Introduction ====
* Why being fast matters
* Challenges
==== Defining test parameters ====
* The mobile case
* Tools
==== How to measure performance ====
* WebPageTest and the critical path
* Start Render, Meaningful Paint, Speed Index...
==== Mastering the cache ====
* Classic cache, standard invalidation
* Strategies and tools in practice
==== Web browsers and HTTP ====
* Understanding latency theory
* HTTP/2, HTTP/3
* HTTPS
==== The critical path ====
* CSS/JS loading strategies
* Preloading
* Compression
==== Fonts ====
* Problems: FOIT, FOUT or white page?
* Optimisation techniques
* Native APIs
==== Images ====
* JPG vs GIF vs PNG vs newer standards
* Loading: normal, inline or lazy?
* Compression techniques and tools
* SVG and icon fonts
==== Third parties ====
* Dangers
* Integrating correctly
==== Loading javascript ====
* The 6 ways to load JS
* Optimising a Webpack bundle
==== Responsive UIs ====
* Good DOM (and jQuery) practices
* Browsers: layout, paint, composition
* Understanding the JS/CSS profiler
* Long and repetitive tasks
==== Monitoring performance ====
* Synthetic
* RUM
==== Customising WebPageTest ====
* Testing complex scenarios
==== Offline support ====
* Service workers, PWAs and Application Cache
==== User perception ====
* User psychology
* UI examples
Frontend
Performance/Graphite (synthetic instance)/Runbook

This is the run book for the Graphite instance used by QTE for performance and other related metrics. 
==Meta==
*Issue tracker (Phabricator): synthetic-performance-testing
*Documentation: Graphite
== Debug missing metrics ==
If metrics stops arriving in Grafana the reason can be two different reasons: Either something is wrong with Graphite or something is broken on the server that runs the performance tests. First check the #synthetic-tests-error-reporting Slack channel and see if you have any related errors in that channel. If there's problems with the Graphite server, the Slack channel should be flooded with messages that metrics cannot be sent to Graphite.
Log into the server and check the status Graphite. First switch to the correct user: sudo su - graphite
Run docker ps to check that the instance is up and running. If not you need to start it. Go to the settings directorycd /home/graphite/settings/ and start docker-compose up
If the Graphite is running but is broken somehow and the restart functionality hasn't fixed the problem you should check the logs:
docker logs --tail 100  settings-graphite-1
== Update to new version ==
You very rarely need to update the Graphite version. However if you need, you update /home/graphite/settings/docker-compose.yml file by changing the version number for the Graphite container then stop and start the container.
Category:Runbooks
Performance/Guides/RUM Alert

This is the runbook for RUM alerts (real user measurements performance alerts).
==Meta==
*Issue tracker (Phabricator): NavigationTiming
*Documentation: Navigation Timing Extension
===RUM performance regression alert===
We alert on three different performance metrics: first paint, response start and load event end. Make sure that you use the alerting metrics in the dashboards when you try find out more about the regression.
Use these steps to try get more information about the regression: 
#Identify when the regression started, so you can use that time stamp when looking in other dashboards. You should be able to see when it happened in the navigation timing alert dashboard
#Is the regression on desktop or mobile or both? Check the navigation metrics by platform dashboard
#Check different percentiles and different metrics to try to understand what has changed) in the navigation timing dashboard.
#Is the regression caused by one browser or by a specific browser version? Check the navigation timing by browser dashboard
#Do we get more or less metrics than before? Check the report rate by metric dashboard
#Can we see the regression using our synthetic tools? Look at the synthetic tests dashboard. If we can see the issue also on WebPageReplay we know it's a front end regression.
#Is the regression caused by a code change? Use time time stamp/ time span when you think the regression started and check the Server Admin Log and the Show sync-wikiversions toggle.
Create a Phabricator task and include everything you know. Please take screenshots of the dashboards and include links. If you could identify the code change that caused the change, please include the team/person in the issue.
Category:Wikimedia Performance
Performance/Guides/Recommended Reads

This is a list of reading material to learn about web performance, as recommended by the Wikimedia Performance.
== Books ==
* Ilya Grigorik - High Performance Browser Networking
* Steven C Seow - Designing and Engineering Time - The Psychology of Time Perception in Software
* Tammy Everts - Time Is Money
* Rick Viscomi, Andy Davies and Marcel Duran - Using WebPageTest
* Lara Hogan - Designing For Performance
== Blogs ==
A list of interesting blogs to follow, in no particular order:
* https://www.brendangregg.com/blog/
* https://nolanlawson.com former Microsoft Edge, Wikipedia-Chromium collab
* https://nicj.net/ Akamai, W3C WebPerf
* https://jakearchibald.com/ Chrome devrel
* https://surma.dev/ Shopify, former Chrome devrel
* https://simonhearne.com/ Elastic
* https://danluu.com/ hardware and systems engineer, former Google/Twitter
* https://wdrl.info/archive Weekly digest
* https://www.sitespeed.io/blog/
* https://tstarling.com/blog/
* https://timotijhof.net/ 
* https://csswizardry.com/archive/
* https://infrequently.org/ Microsoft, former Google Chrome
* https://www.etsy.com/codeascraft/ 
* https://code.flickr.net/
* https://technology.blog.gov.uk/
* https://insidegovuk.blog.gov.uk/ 
* https://hacks.mozilla.org/
* https://tech.trivago.com/ 
* https://v8.dev/
* https://calendar.perfplanet.com/
* https://techblog.wikimedia.org/ 
* https://blog.mozilla.org/performance/
* https://aphyr.com/tags/jepsen
* https://cutlefish.substack.com/
== Misc ==
* https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/README.md Changelogs for the metrics of Google's Core Web Vitals.
* https://almanac.httparchive.org/en/2022/ by Google
* https://www.perfplanet.com/ aggregator with many of the above feeds
Matrix
* https://matrix.to/#/#perftest:mozilla.org Mozilla channel about performance testing
Recommended Reads
Performance/Mobile Device Lab/Raspberry Pi Image

The device lab images are based on the upstream Debian GNU/Linux image. I’ve forked the build scripts to include the additional dependencies we require.
Some of the installation steps still need to be converted to .deb packages.
== Building the image ==
Install the dependencies, per the upstream instructions.
Run make raspi_4_bullseye.img. You don’t need to be root if fakemachine is installed.
I compress the image using pv -s 4G < raspi_4_bullseye.img | xz -8c > devicelab_bullseye.img. (The compress.sh script from upstream doesn’t work as a non-root user and didn’t generate much in the way of space savings when I tested it.)
== Writing the image ==
Run sudo dd if=devlicelab_bullseye.img of=/dev/mmcblk0 bs=8M.
After writing, I run fsck /dev/mmcblk0p2 to check for errors. In the past, I’ve run into issues with no-brand SD cards silently eating data.
If you get garbage on the serial console starting mid-way through the boot sequence, you should mount /dev/mmcblk0p1 and edit cmdline.txt to add module_blacklist=vc4. This works around an upstream bug for me.
== Running the image ==
The default user is wmf, which is in sudoers.
You can configure a static IP or wifi network information by mounting the image (or, if you have console access, booting and logging in) and editing the files in /etc/network/interfaces.d. Wireguard is included, and soon the image will contain startup scripts to automatically “phone home” with a VPN connection for talking to the attached devices.
If you’re connection a modern Android device, the usb0 interface corresponds to a USB ethernet interface that can be used for reverse tethering. Otherwise, either Web Page Relay or gnirehtet can be used to tunnel web traffic over the USB interface. Work is in progress to make both solutions work better out of the box.
Sitespeed.io is installed for running mobile tests. Our current test setup is in [Gerrit https://gerrit.wikimedia.org/g/performance/mobile-synthetic-monitoring-tests/+/refs/heads/master].
Category:Wikimedia Performance
Performance/Mobile Device Lab/Requirements

== Requirements for the mobile device lab ==
=== Phones ===
* Model & Performance: We're using Moto G5 and Samsung A51 Android phones. They reflect the CPU speed of our primary user base in certain countries. In the future we also want to run Apple devices.
* Root Access: Some phones need to be rooted. This allows us to control the CPU speed consistently, aiding in stable performance metrics.
* Application Updates: Regular updates are crucial and we need to able to choose exact when those happen. We upgrade Chrome and Firefox upon each new stable release.
* Screen Monitoring: We utilise scrcpy for screen viewing. That helps us update and find problems on the phone.
* Temperature Control: To avoid performance changes due to heating, we monitor and control the battery (and by extension, CPU) temperature. You need to make sure that the phones are cold.
* No cellular service: The phones do not need any cellular service. They will use either a wifi or the internet connection from the server.
* Wifi connection: Preferable the phones can connect to a wifi. That is good when we need to run upgrades and then can use the Play store.
=== Servers ===
* One Server Per Phone: Ideally, each phone is tethered to a dedicated server. This setup allows for independent and varied connectivity settings.
* Server Specifications:
** Can be Raspberry Pi or any Linux-based system (ARM or AMD).
** Requires USB connection to phone.
** Ethernet access with internet.
** We need to be able to access the server using SSH
* Data Handling: Servers will upload data to S3, send metrics to Graphite, and use Redis for server-to-server communication.
* Raspberry Pi Usage: For Raspberry Pi servers, VNC is used for screen access. 
=== Network ===
* Stability & Realism: We aim for a consistently stable network, simulating 3G/4G conditions by controlling speed and adding delays.
* Connection Methods:
** Tethering from the server is preferred for stability. We use Linux Traffic Control (tc) on the tethered connection.
** We tried sharing the WiFi from Raspberry Pis and that works fine but if there's many WiFis it seems to be good to have one phone per WiFi source.
** We tested a Netropy device but tethering or Raspberry Pi WiFi gets us more stable network performance.
=== Example setup and workflow ===
* Previous Setup Example: We ran tests on phones accessing Wikipedia, driven by a server running sitespeed.io. Tests, configurations, and URLs were managed from a public Git repository. Metrics were sent to Graphite, with test results stored on S3. WebPageReplay was also used for stable metric comparisons.
* Upcoming Changes: Some servers will connect to Redis for new job assignments.
Performance/Performance Residency

The Performance Residency is a training program aimed at elevating the web performance skills and practices of the Wikimedia Foundation as a whole. It consists of the Performance Team welcoming a temporary team member for the duration of one financial quarter.
At this time this program isn't available to volunteer contributors, we will revisit that policy if it proves to be successful with staff members first.
== Rationale ==
Presentation-based training has its limits and the complex field of web performance is best learned by doing.
While training one person at a time might seem inefficient, the goal is to create performance heroes who will go back to their respective teams after the training as advocates of performance, spreading performance knowledge and best practices around them.
During the residency participants will work on projects/features they're familiar with. The goal is that we find a mutually beneficial project for the participant's team of origin. In this sense, the residency isn't a sabbatical-like break from the participant's home team, but a quarter-length sharp focus on performance.
== Requirements ==
In order to participate, participants need to be full-time WMF employees or contractors (#req holder).
Participants need their manager's approval to participate in this program.
== Principles ==
* The duration is exactly one financial quarter. No more, no less. Participants can only do one residency. Participants may apply as many times as they want until they are accepted.
* There is currently one spot available per quarter. We might increase this if we feel that we can take on more.
* Prospective participants must apply at least 30 calendar days before the beginning of the financial quarter.
* The quarterly goal(s) of the residency must be the only goal(s) of the participant for the quarter.
* The project(s) must be directly related to the participant's team of origin. For example if the participant is a member of the Editing team, a suitable project might be optimising VisualEditor performance.
* Participants will be attending Performance Team weekly meetings and if budget allows Performance Team offsites that may happen during that quarter. They will be treated as equal members of the Performance Team and are expected to fully engage in the team activities.
== How can I apply? ==
Contact us at performance-team at wikimedia.org :)
Performance Residency
Performance/Runbook/SyntheticToolAlert

This is the runbook for Synthetic tool alerts that will fire when one of the tools are down or we are missing data from that tool.
==Meta==
*Issue tracker (Phabricator): WebPageTest WebPageReplay
*Documentation: WebPageTest WebPageReplay
== WebPageReplay missing data ==
# Check if the WebPageReplay server is running by login to the machine. 
#Check the log file located at /tmp/sitespeed.io.log. Can you see any errors in the log?
#If the log files seems stuck (nothing has happened in the log for one our or so) check if the container is stuck by listing container status docker ps. If the created date is more than one hour ago you know something is wrong, because we a start new containers something like every 10 minutes. Kill the container docker kill <container name> then wait some time, check that a new container is up and running with docker ps and then verify that everything looks ok in the log,
== WebPageReplay CPU benchmark alert ==
The CPU benchmark measures how stable the metrics/CPU is on the machine that runs the tests. If it is unstable for some time you need to deploy the tests on a new server.
== WebPageReplay TTFB alert ==
The TTFB (time to first byte) should be really stable when you use WebPageReplay since the tests runs on the same server as the browser. If you have high variation in TTFB something is really wrong on the server and you should try to deploy the tests on a another server.
== CRUX missing data ==
The Crux (Chrome user experience report) data is collected once a day with a job that runs in the crontab.
# Login to the server that collect the data from the Chrome User Experience Report API: ssh crux-metrics.webperformancetest.eqiad1.wikimedia.cloud
# Check the log located in /tmp/sitespeed.io.log to see if you see any errors
# If you found out what's wrong and you fix it, you can manually run the four tests that collects the data (look in. the crontab on how to do that). It doesn't matter when you run the tests, as long as you run them once per day (else we will miss out on data).
== sitespeed.io missing data ==
* Check if the sitespeed.io server is running by login to the machine.
* Check the log file located at /tmp/sitespeed.io.log. Can you see any errors in the log?
* If the log files seems stuck (nothing has happened in the log for one our or so) check if the container is stuck by listing container status docker ps. If the created date is more than one hour ago you know something is wrong, because we a start new containers something like every 10 minutes. Kill the container docker kill <container name> then wait some time, check that a new container is up and running with docker ps and then verify that everything looks ok in the log,