3 ms·

This isn't just a frontend optimization that can be applied in isolation by a good dev. With WS or SSE there now needs to be server written & supported to push

This isn't just a frontend optimization that can be applied in isolation by a good dev. With WS or SSE there now needs to be server written & supported to push this data over. On top of all the networking issues that come with these streaming protocols. > Why shouldn't they care about their performance too? They definitely do this for everything they push out that runs on billions of devices for people all over the world. How many people use Google to keep track of the live score of "the Laver Cup tennis championship in Australia?" I'd be surprised if that's more than 100. But Google has these numbers, and based on that they've chosen not to optimize this.

nostrademons 7y ago
There's also the issue of optimizing for users of sports fans but pessimizing for the general population. Say that they do this "right" and include a real-time websockets client that has all the proper reconnect logic, uses a minified protocol, has a proper real-time stack on the backend with all the appropriate DDoS protection, encryption, CORS, etc. All the client logic is extra bytes that need to be shipped on every search request. Or they could split the bundle and lazy-load it, which is still extra bytes, but fewer of them, and adds complexity. The server code needs to be audited for security; one compromised frontend server and the damage to Google is already more than the entire value of the feature. One black-swan websearch outage (caused, say, by a misconfiguration leading to the load balancers getting slammed by websocket connections, or a misconfiguration causing the DDoS servers to think websearch is actually undergoing a DDoS when it's just normal websocket traffic) is already more than the entire value of the feature. The bar for simplicity and reliability has to be pretty high for a feature that's going to be used by 0.0001% of users, because if there are any negative effects at all on mainstream websearch traffic, that feature should never have been launched.
- matt_oriordan 7y ago
  I agree complexity should be avoided. But I don't really follow the logic that if every feature can break security, reliability, etc. you should never change anything or progress. Google is doubling down on these features as you can see at https://www.seroundtable.com/google-pin-live-scores-28261.html https://www.seroundtable.com/google-pin-live-scores-28261.ht.... If they're continuing to invest in adding more realtime features, and penalising sites in search results that don't optimise their websites https://www.sitecenter.com/insights/141-google-introduces-penalty-for-slow-websites.htm https://www.sitecenter.com/insights/141-google-introduces-pe..., then I think they should apply that same logic to their own site IMHO.
  - summerlight 7y ago
    Probably that's why Google is trying to improve network protocols (QUIC, HTTP/3) rather than relying on one-off optimizations described in the article.
    - matt_oriordan 7y ago
      How does QUIC or HTTP/3 change things? Polling is polling, regardless of whether it's over HTTP/1, HTTP/2 or HTTP/3 (QUIC).
      - summerlight 7y ago
        It still optimizes overall network efficiency much more than enough to negate 0.001% inefficient cases using polling? I would say this is a right prioritization of optimization engineer headcounts, which is pretty scarce.
matt_oriordan 7y ago
This feature is not for the Laver Cup, it's for all sports events and scores they have access to, and has been so since 2016 - http://www.thesempost.com/google-adds-live-sports-scores-search-results/ http://www.thesempost.com/google-adds-live-sports-scores-sea...

nostrademons 7y ago

There's also the issue of optimizing for users of sports fans but pessimizing for the general population. Say that they do this "right" and include a real-time websockets client that has all the proper reconnect logic, uses a minified protocol, has a proper real-time stack on the backend with all the appropriate DDoS protection, encryption, CORS, etc. All the client logic is extra bytes that need to be shipped on every search request. Or they could split the bundle and lazy-load it, which is still extra bytes, but fewer of them, and adds complexity. The server code needs to be audited for security; one compromised frontend server and the damage to Google is already more than the entire value of the feature. One black-swan websearch outage (caused, say, by a misconfiguration leading to the load balancers getting slammed by websocket connections, or a misconfiguration causing the DDoS servers to think websearch is actually undergoing a DDoS when it's just normal websocket traffic) is already more than the entire value of the feature. The bar for simplicity and reliability has to be pretty high for a feature that's going to be used by 0.0001% of users, because if there are any negative effects at all on mainstream websearch traffic, that feature should never have been launched.

matt_oriordan 7y ago
I agree complexity should be avoided. But I don't really follow the logic that if every feature can break security, reliability, etc. you should never change anything or progress. Google is doubling down on these features as you can see at https://www.seroundtable.com/google-pin-live-scores-28261.html https://www.seroundtable.com/google-pin-live-scores-28261.ht.... If they're continuing to invest in adding more realtime features, and penalising sites in search results that don't optimise their websites https://www.sitecenter.com/insights/141-google-introduces-penalty-for-slow-websites.htm https://www.sitecenter.com/insights/141-google-introduces-pe..., then I think they should apply that same logic to their own site IMHO.
- summerlight 7y ago
  Probably that's why Google is trying to improve network protocols (QUIC, HTTP/3) rather than relying on one-off optimizations described in the article.
  - matt_oriordan 7y ago
    How does QUIC or HTTP/3 change things? Polling is polling, regardless of whether it's over HTTP/1, HTTP/2 or HTTP/3 (QUIC).
    - summerlight 7y ago
      It still optimizes overall network efficiency much more than enough to negate 0.001% inefficient cases using polling? I would say this is a right prioritization of optimization engineer headcounts, which is pretty scarce.

matt_oriordan 7y ago

This feature is not for the Laver Cup, it's for all sports events and scores they have access to, and has been so since 2016 - http://www.thesempost.com/google-adds-live-sports-scores-search-results/ http://www.thesempost.com/google-adds-live-sports-scores-sea...