Change Details

* Affected components: Wikimedia site configuration. * Engineer for implementing the change: Core Platform Team (WMF) and SRE ServiceOps (WMF). * Code steward: (idem). ### Motivation The m. subdomain, as in en.m.wikipedia.org, is annoying. Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site. Having separate domains complicates analytics and search engine optimisation. The m. subdomain does not appear to reflect best current practice. Many websites are able to detect mobile clients and deliver the correct variant through an unmodified URL. For example, WikiTravel does this, using CloudFront and MediaWiki/MobileFrontend. ##### Requirements 1. When browsing Wikipedia from mobile web or desktop, and sharing the browser address with someone, the address should produce the default Wikipedia experience for the receiver's end. ------- ### Exploration The first requirement means we either have to redirect in both directions, or vary the server response without a redirect. The latter seems simple and also more performant for the end-user by not having a significant portion of page views delayed by an additional blocking/synchronous client-server roundtrip over the network. I propose removing the m. subdomain. The frontend would detect the desired device variant based on UA and request cookies, and send it to MediaWiki in a single header, and would vary the resulting cache based on this request header. MediaWiki (MobileFrontend, or core after T100402 is fixed) would use this request header to select the skin. @bblack suggests starting with a soft launch. We would initially remove the device detection redirect from en.wikipedia.org to en.m.wikipedia.org. We would redirect away from the old domains only when the traffic on them has declined. Obviously, to avoid breaking links, the redirect will have to be retained forever. We could look at how device detection works in third-party CDNs for ideas on what to call the request header or any other unresolved details. ------- Known issues * {T74186} * {T60425} * {T171398}

* Affected components: Wikimedia site configuration. * Engineer for implementing the change: Core Platform Team (WMF) and SRE ServiceOps (WMF). * Code steward: (idem). ### Motivation The m. subdomain, as in en.m.wikipedia.org, is annoying. Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site. Having separate domains complicates analytics and search engine optimisation. The m. subdomain does not appear to reflect best current practice. Many websites are able to detect mobile clients and deliver the correct variant through an unmodified URL. For example, WikiTravel does this, using CloudFront and MediaWiki/MobileFrontend. ##### Requirements 1. When browsing Wikipedia from mobile web or desktop, and sharing the browser address with someone, the address should produce the default Wikipedia experience for the receiver's end. ------- ### Exploration The first requirement means we either have to redirect in both directions, or vary the server response without a redirect. The latter seems simple and also more performant for the end-user by not having a significant portion of page views delayed by an additional blocking/synchronous client-server roundtrip over the network. I propose removing the m. subdomain. The frontend would detect the desired device variant based on UA and request cookies, and send it to MediaWiki in a single header, and would vary the resulting cache based on this request header. MediaWiki (MobileFrontend, or core after T100402 is fixed) would use this request header to select the skin. @bblack suggests starting with a soft launch. We would initially remove the device detection redirect from en.wikipedia.org to en.m.wikipedia.org. We would redirect away from the old domains only when the traffic on them has declined. Obviously, to avoid breaking links, the redirect will have to be retained forever. We could look at how device detection works in third-party CDNs for ideas on what to call the request header or any other unresolved details. ------- Known issues * {T74186} * {T60425} * {T171398} * {T225814}

* Affected components: Wikimedia site configuration. * Engineer for implementing the change: Core Platform Team (WMF) and SRE ServiceOps (WMF). * Code steward: (idem). ### Motivation The m. subdomain, as in en.m.wikipedia.org, is annoying. Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site. Having separate domains complicates analytics and search engine optimisation. The m. subdomain does not appear to reflect best current practice. Many websites are able to detect mobile clients and deliver the correct variant through an unmodified URL. For example, WikiTravel does this, using CloudFront and MediaWiki/MobileFrontend. ##### Requirements 1. When browsing Wikipedia from mobile web or desktop, and sharing the browser address with someone, the address should produce the default Wikipedia experience for the receiver's end. ------- ### Exploration The first requirement means we either have to redirect in both directions, or vary the server response without a redirect. The latter seems simple and also more performant for the end-user by not having a significant portion of page views delayed by an additional blocking/synchronous client-server roundtrip over the network. I propose removing the m. subdomain. The frontend would detect the desired device variant based on UA and request cookies, and send it to MediaWiki in a single header, and would vary the resulting cache based on this request header. MediaWiki (MobileFrontend, or core after T100402 is fixed) would use this request header to select the skin. @bblack suggests starting with a soft launch. We would initially remove the device detection redirect from en.wikipedia.org to en.m.wikipedia.org. We would redirect away from the old domains only when the traffic on them has declined. Obviously, to avoid breaking links, the redirect will have to be retained forever. We could look at how device detection works in third-party CDNs for ideas on what to call the request header or any other unresolved details. ------- Known issues * {T74186} * {T60425} * {T171398} * {T225814}