igrigorik

<igrigorik> Ilya Grigorik agenda: https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#
11:07 Doug: NEL and Reporting moved from WICG to WebPerf
11:07 ... we have i2s LGTM's for both in Chrome
11:07 ... we'll be launching as stable experiments this quarter
11:07 ... we should have live implementation in chrome by EOQ
11:08 ... some good feedback from i2s process, which  resulted in spec updates
11:08 ... one common question from TAG was about using JSON in headers
11:09 ... we got some pushback from TAG on JSON; there are known gotchas with JSON — e.g. numbers.
11:09 ... alternative would be to use structured headers (being developed by httpwg / IETF)
11:10 ... after some analysis, we ended *not* doing that and sticking with JSON

igrigorik

Keybase proof

I hereby claim:

• I am igrigorik on github.
• I am igrigorik (https://keybase.io/igrigorik) on keybase.
• I have a public key whose fingerprint is 873B C0D7 3D56 C15C D67A 9F0E 9F75 9AC6 6FD4 B89B

To claim this, I am signing this object:

igrigorik

> performance.getEntriesByName('W3C-meetup')
> [ PerformanceEvent
         name: "W3C WebPerf meetup"
    startTime: "5:30pm–7:30pm Wednesday"
     location: "Ballroom CD"
    entryType: "Unconference"
       topics: "latest & upcoming perf APIs, feature requests, bugs, feedback, …"
  ]

igrigorik

var DOMTokenListSupports = function(tokenList, token) {
  if (!tokenList || !tokenList.supports) {
    return;
  }
  try {
    return tokenList.supports(token);
  } catch (e) {
    if (e instanceof TypeError) {
      console.log("The DOMTokenList doesn't have a supported tokens list");
    } else {

igrigorik

$> ls -al index.html
-rw-r--r--   1 igrigorik  5000  21854 Dec  3 14:57 index.html

$> curl -vv --compressed http://w3c.github.io/preload/
*   Trying 199.27.79.133...
* Connected to w3c.github.io (199.27.79.133) port 80 (#0)
> GET /preload/ HTTP/1.1
> Host: w3c.github.io
> User-Agent: curl/7.43.0
> Accept: */*

igrigorik

SELECT * FROM
(SELECT 'desktop' type,
  NTH(50, quantiles(bytesCSS)) median,
  NTH(75, quantiles(bytesCSS)) seventy_fifth,
  NTH(90, quantiles(bytesCSS)) ninetieth
FROM [httparchive:runs.latest_pages]),
(SELECT 'mobile' type,
  NTH(50, quantiles(bytesCSS)) median,
  NTH(75, quantiles(bytesCSS)) seventy_fifth,
  NTH(90, quantiles(bytesCSS)) ninetieth

igrigorik

/* count number of pushes between Jan 1 and Jan 5  */
SELECT 
  COUNT(*) 
FROM `githubarchive.day.2015*`
WHERE 
  type = 'PushEvent'
  AND (_TABLE_SUFFIX BETWEEN '0101' AND '0105')
  
/* count number of watches between Jan~Oct 2014 */
SELECT COUNT(*) 

igrigorik

/* count of issues opened, closed, and reopened on 2019/01/01 */
SELECT event as issue_status, COUNT(*) as cnt FROM (
  SELECT type, repo.name, actor.login,
    JSON_EXTRACT(payload, '$.action') as event, 
  FROM `githubarchive.day.20190101`
  WHERE type = 'IssuesEvent'
)
GROUP by issue_status;

igrigorik

Navigation and Resource Timing provides timing data for the fetch, but currently there is no interoperable way for the server to communicate own timing information to the client. For example:

• What steps were taken to generate the resource, and how long each took. Many sites already embed this type of information via HTML comments - e.g. wordpress emits <!--Page generated in X.X seconds.--> , and many sites provide more detailed stats (cache, db, generation) to enable performance debugging.
• If proxied, where was the time spent - e.g. time to fetch from origin, time to process response, etc.

Instead of relying on arbitrary HTML comments, we can define an HTTP header that can be used to send key-value pairs in a well defined format. Making this data available via a well defined interface would...

• Allow UA and other developer tools to automatically annotate appropriate timelines.
• Allow analytics vendors to gather this data for operational analysis.
• Allows proxies and CDNs to append custom timing d

igrigorik

Android	iOS	Gen	Down max
NETWORK_TYPE_CDMA		2G
NETWORK_TYPE_IDEN		2G
NETWORK_TYPE_GPRS	CTRadioAccessTechnologyGPRS	2.5G
NETWORK_TYPE_EDGE	CTRadioAccessTechnologyEdge	2.75G
NETWORK_TYPE_1xRTT	CTRadioAccessTechnologyCDMA1x	3G
NETWORK_TYPE_UMTS	CTRadioAccessTechnologyWCDMA	3G
NETWORK_TYPE_EVDO_0	CTRadioAccessTechnologyCDMAEVDORev0	3.5G
NETWORK_TYPE_EVDO_A	CTRadioAccessTechnologyCDMAEVDORevA	3.5G