Disclaimer: The following describes using of experimental features with dubious effects. Make sure to test for introduced regressions and actual performance gains.

You could try some of Google Chrome's / Chromium's flags under under chrome://flags to improve the (apparent) browsing performance.

Forcing GPU acceleration in by enabling "Overwrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

After enabling/disabling any switches, you will have to restart Chrome/Chromium for the setting to apply. The button at the bottom of the flags-page can do that for you.

Going even further, command line switches could be used to optimize Chrome/Chromium. See the List of Chromium Command Line Switches for a complete list.

--default-tile-width and --default-tile-height could be set to match a fraction of the screen size to speed up initial rendering of each page.

Disclaimer: The following describes using of experimental features with dubious effects. Make sure to test for introduced regressions and actual performance gains.

You could try some of Google Chrome's / Chromium's flags under under chrome://flags to improve the (apparent) browsing performance. There is an article explaining some of the flags relevant to performance. I will try to collect some here:

Forcing GPU acceleration in by enabling "Overrrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

GPU compositing on all pages will use the GPU to scroll all layers. So scrolling performance should improve on pages without GPU-accelerated layers.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

Disable GPU VSync will update the rendered contents regardless of whether the monitor has loaded them yet. This improves the frame rate at the cost of inconsistent presentation.

After enabling/disabling any switches, you will have to restart Chrome/Chromium for the setting to apply. The button at the bottom of the flags-page can do that for you.

Going even further, command line switches could be used to optimize Chrome/Chromium. See the List of Chromium Command Line Switches for a complete list.

--default-tile-width and --default-tile-height could be set to match a fraction of the screen size to speed up initial rendering of each page.

Disclaimer: The following describes using of experimental features with dubious effects. Make sure to test for introduced regressions and actual performance gains.

You could try some of Google Chrome's / Chromium's flags under under chrome://flags to improve the (apparent) browsing performance.

Forcing GPU acceleration in by enabling "Overwrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

Going even further, command line switches could be used to optimize Chrome/Chromium. See the List of Chromium Command Line Switches for a complete list.

--default-tile-width and --default-tile-height could be set to match a fraction of the screen size to speed up initial rendering of each page.

Disclaimer: The following describes using of experimental features with dubious effects. Make sure to test for introduced regressions and actual performance gains.

You could try some of Google Chrome's / Chromium's flags under under chrome://flags to improve the (apparent) browsing performance.

Forcing GPU acceleration in by enabling "Overwrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

After enabling/disabling any switches, you will have to restart Chrome/Chromium for the setting to apply. The button at the bottom of the flags-page can do that for you.

Going even further, command line switches could be used to optimize Chrome/Chromium. See the List of Chromium Command Line Switches for a complete list.

--default-tile-width and --default-tile-height could be set to match a fraction of the screen size to speed up initial rendering of each page.