PT-Logo
Forgot your password?
BenchmarkXPRT Blog banner

Tag Archives: Chrome

Planning for the next CrXPRT

We’re currently planning the next version of CrXPRT, our benchmark that evaluates the performance and battery life of Chromebooks. If you’re unfamiliar with CrXPRT, you can find out more about how it works both here in the blog and at CrXPRT.com. If you’ve used CrXPRT, we’d love to hear any suggestions you may have. What do you like or dislike about CrXPRT? What features do you hope to see in a new version?

When we begin work on a new version of any benchmark, one of our first steps is to determine whether the workloads will provide value during the years ahead. As technology and user behavior evolve, we update test content to be more relevant. One example is when we replace photos with ones that use more contemporary file resolutions and sizes.

Sometimes the changing tech landscape prompts us to remove entire workloads and add new ones. The Photo Collage workload in CrXPRT uses Portable Native Client (PNaCl) technology, for which the Chrome team will soon end support. CrXPRT 2015 has a workaround for this issue, but the best course of action for the next version of CrXPRT will be to remove this workload altogether.

The battery life test will also change. Earlier this year, we started to see unusual battery life estimates and high variance when running tests at CrXPRT’s default battery life test length of 3.5 hours, so we’ve been recommending that users perform full rundowns instead. In the next CrXPRT, the battery life test will require full rundowns.

We’ll also be revamping the CrXPRT UI to improve the look of the benchmark and make it easier to use, as we’ve done with the other recent XPRT releases.

We really do want to hear your ideas, and any feedback you send has a chance to shape the future of the benchmark. Let us know what you think!

Justin

A CrXPRT fix for Chrome 76

After Chrome OS version 76 moved from Chrome’s Beta channel to the Stable channel last week, we became aware of an issue that occurs when CrXPRT’s Photo Collage workload runs on a Chrome 76 system. We found that the Photo Collage workload produces an error message—“This plugin is not supported on this device”—and the test run does not complete.

The error occurs because the Photo Collage workload uses Portable Native Client (PNaCl), and starting with version 76, the Chrome team changed the way the OS handles PNaCl tasks. Technically, Chrome still supports PNaCl, but the OS now disables the capability by default. Chrome’s current plan is to end support for PNaCl by the end of this year, focusing related development efforts on WebAssembly instead.

We’ll investigate the best path forward during this transition, but for now, testers can use the following workaround that allows CrXPRT to complete successfully. Simply navigate to chrome://flags on the test system, and find the Native Client flag, which is set to “Disabled” by default. Click the toggle switch to “Enabled” to allow native client capabilities, restart the system, and kick off a CrXPRT test in the normal manner.

We’ll update the CrXPRT web page and test documentation to include information about the workaround. In the long term, we’re interested in any suggestions you have for CrXPRT—whether they’re related to PNaCl or not. Please let us know your thoughts!

Justin

A new playing field for WebXPRT

WebXPRT is one of the go-to benchmarks for evaluating browser performance, so we’re always interested in browser development news. Recently, Microsoft created a development channel where anyone can download early versions of an all-new Microsoft Edge browser. Unlike previous versions of Edge, Microsoft constructed the new browser using the Chromium open-source project, the same foundation underlying the Google Chrome browser and Chrome OS.

One interesting aspect of the new Edge development strategy is the changes that Microsoft is making to more than 50 services that Chromium has included. If you use Chrome daily, you’ve likely become accustomed to certain built-in services such as ad block, spellcheck, translate, maps integration, and form fill, among many others. While each of these is useful, a large number of background services running simultaneously can slow browsing and sap battery life. In the new Edge, Microsoft is either reworking each service or removing it altogether, with the hope of winning users by providing a cleaner, faster, and more power-efficient experience. You can read more about Microsoft’s goals for the new project on the Microsoft Edge Insider site.

As we’ve discussed before, many factors contribute to the speed of a browsing experience and its WebXPRT score. It’s too early to know how the new Microsoft Edge will stack up against other browsers, but when the full version comes out of development, you can be sure that we’ll be publishing some comparison scores. I’ve installed the Dev Channel version of Edge on my personal machine and run WebXPRT 3. While I can’t publish the scores from this early version, I can tell you that the results were interesting. Have you run WebXPRT 3 on the new Microsoft Edge? How do you think it compares to competitors? We’d love to hear your thoughts.

JNG

CrXPRT in the Chrome Web Store

Testers searching for CrXPRT in the Chrome Web Store may be puzzled to see “no results.” While CrXPRT no longer appears in Chrome Web Store searches, the app is still live in the store and there’s nothing wrong with it. CrXPRT is freely available and functioning normally, but you can access it only through a direct link. It’s an unusual situation that results from a strategic decision by the Chrome team, a decision affecting many apps in addition to CrXPRT.

For several years, Chrome supported two types of apps—hosted apps that wrap online websites, and packaged apps that have offline capability. CrXPRT is a packaged app built for Chrome OS. In December 2017, the Chrome team stopped providing search and browse functions for hosted and packaged apps in the Chrome Web Store. Instead, they’re encouraging folks to develop Progressive Web Apps. You can read about the reasoning behind this decision on the Chromium blog. Despite this shift in focus, the Chrome Web store will continue to support existing apps packaged for Chrome OS.

In short, the Chrome Web Store will support CrXPRT for the foreseeable future, and we’ll continue to issue any necessary bug fixes through the store. With the help of the community, we’ll reevaluate CrXPRT next year and decide the best way forward for the app. In the meantime, you can access CrXPRT from the direct link below and from CrXPRT.com. Note that the direct link may take you to a splash page if you use an unsupported platform.

CrXPRT 2015: https://chrome.google.com/webstore/detail/crxprt/hiajijaeaacmnpjpkcfnhohmaijanjgf

Please let us know if you have any questions.

Justin

WebXPRT and user-agent strings

After running WebXPRT in Microsoft Edge, a tester recently asked why the browser information field on the results page displayed “Chrome 52 – Edge 15.15063.” It’s a good question; why would the benchmark report Chrome 52 when Microsoft Edge is the browser under test? The answer lies in understanding user-agent strings and the way that WebXPRT gathers specific bits of information.

When browsers request a web page from a hosting server, they send an array of basic header information that allows the server to determine the client’s capabilities and the best way to provide the requested content. One of these headers, the user-agent, presents a string of tokens that provide information about the application making the request, the operating system and version, rendering engine compatibility, and browser platform details. In effect, the user-agent string is a way for a browser to tell the hosting server the full extent of its capabilities.

When WebXPRT attempts to identify a browser, it references the browser token in the user-agent string.

The process is generally straightforward, but in some cases, browsers spoof information from other browsers in their user-agent strings, which makes accurate browser detection difficult. The reasons for this are complex, but they involve web development practices and the fact that some web pages are not designed to recognize and work well with new or less-popular browsers. When we released WebXPRT 2015, Microsoft Edge was new. The Edge team wanted to make sure that as much advanced web content as possible would be available to Edge users, so they created a user-agent string that declared itself to be several different browsers at once.

I can see this in action if I check Edge’s user-agent string on my system. Currently, it reports “Mozilla/5.0 (Windows NT 10.0; Win64; x64; ServiceUI 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063.” So, because of the way Edge’s user-agent string is constructed, and the way WebXPRT parses that information, the browser information field on WebXPRT’s results page will report “Chrome 52 – Edge 15.15063” on my system.

To try this on your system, in Edge, select the ellipses icon in the top right-hand corner, then F12 Developer Tools. Next, select the Console tab, and run “javascript:alert(navigator.userAgent).” A popup window will display the UA string.

You can find instructions for finding the user-agent string in other browsers here: http://techdows.com/2016/07/edge-ie-chrome-firefox-user-agent-strings.html.

In the next version of WebXPRT, we’ll work to refine the way that the test parses user-agent strings, and provide more accurate system information for testers. If you have any questions or suggestions regarding this topic, let us know!

Justin

Check out the other XPRTs: