4 ms·

And GoogleBot seems to follow Safari's rendering instead of Chrome: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcodepen.io%2FMarti

And GoogleBot seems to follow Safari's rendering instead of Chrome: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcodepen.io%2FMartijnCuppens%2Fpen%2FMXojmw&tab=desktop https://developers.google.com/speed/pagespeed/insights/?url=...

Operyl 8y ago
I wonder if that’s because they’re just running an older version of WebKit/blink.
- kevingadd 8y ago
  "Chrome's" rendering in many cases is going to be whatever hardware accelerated stack (probably Skia + your platform's particular hardware API) is rasterizing the page. Headless rendering as found in a page scraper bot is more likely to be using software rasterization and might be using an entirely different API. Chrome has a few command line flags that can push everything through different rendering paths and you can get different results from it.
  - bla2 8y ago
    Blink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.
    - LukeShu 8y ago
      I wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.
      - gsnedders 8y ago
        Nah, this will all be handled within Blink. The drawing command will literally be told to draw polygons in the specific places in the coordinate space.
    - kevingadd 8y ago
      "shouldn't", but historically I've observed that different backends have different behavior for filtering (of bitmaps and layers) and for text rasterization. Wouldn't be surprised if geometry rasterization could be different too.
bwbw223 8y ago
Maybe chrome/blink require too much ram so they used WebKit /s

4 ms·

And GoogleBot seems to follow Safari's rendering instead of Chrome: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcodepen.io%2FMarti

by webwebweb 8y ago

Operyl 8y ago
I wonder if that’s because they’re just running an older version of WebKit/blink.
- kevingadd 8y ago
  "Chrome's" rendering in many cases is going to be whatever hardware accelerated stack (probably Skia + your platform's particular hardware API) is rasterizing the page. Headless rendering as found in a page scraper bot is more likely to be using software rasterization and might be using an entirely different API. Chrome has a few command line flags that can push everything through different rendering paths and you can get different results from it.
  - bla2 8y ago
    Blink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.
    - LukeShu 8y ago
      I wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.
      - gsnedders 8y ago
        Nah, this will all be handled within Blink. The drawing command will literally be told to draw polygons in the specific places in the coordinate space.
    - kevingadd 8y ago
      "shouldn't", but historically I've observed that different backends have different behavior for filtering (of bitmaps and layers) and for text rasterization. Wouldn't be surprised if geometry rasterization could be different too.
bwbw223 8y ago
Maybe chrome/blink require too much ram so they used WebKit /s