About half the memory of the reference browser on everyday sites
A memory release, measured on sites picked at random rather than sites we tuned for. On 33 popular websites, opened in Floati and in the reference browser on the same Mac at the same screen sharpness, Floati used 5,777 MB in total against 10,377 MB: 44 percent less, and less on 28 of the 33. Against 0.1.376 it is a bigger change still: on the 26 sites 0.1.376 handled normally, memory fell from 10,158 MB to 4,658 MB, and six of the sites made 0.1.376 run away to between 2 and 22 GB; all six now settle at a few hundred MB. Getting there meant fixing real bugs those sites showed: a page whose style sheet was left unfinished now looks styled, carousels built on a very common script library show their slides, the most common way of holding floated boxes together works, animated images no longer keep every frame in memory, a video and a page of frames inside frames can no longer eat gigabytes, and a news site whose server sends a less common character in its headers now loads. Measured and tested on a Mac; the Windows build passes the same engine tests.
Measured on random sites, against the reference browser
We took 35 sites at random from a public list of the most visited websites: news, shops, a university, a bank, government, software makers, a wiki in Korean, a recipe site in Japanese. Each was opened in Floati and in the reference browser on the same Mac, both drawing at twice the pixel density (a Retina screen), and we counted all the memory each browser used for it once the page had settled, every process of the reference browser included. Two sites could not be compared: a bank whose certificate is not publicly trusted (neither browser opens it) and a financial news site that shows Floati a robot check instead of its page. On the other 33 Floati used 5,777 MB and the reference browser 10,377 MB: 44 percent less. Floati used less on 28 of them, often far less (a portal 95 MB against 696, a learning site 69 against 331). It still uses more on five: a maths software site and a science magazine, where large photos are kept at more pixels than they are drawn at, a government site with a 4K video, a shop and a search page. Those are the next targets.
Pages that came out broken now look right
Testing on random sites found bugs the usual test pages never hit. A chipmaker's home page came out as a bare list of links: one of its inline style sheets ended with two blocks left open and its main sheet with an unfinished comment, so every rule after it was read as part of the broken one. A style sheet left open at its end is now closed there, as the standard says. With that fixed, its carousel showed every slide stacked on top of each other: the carousel script counts with a number that starts as text, and adding one to the text "0" gave "01" instead of 1, so the very common script library it uses only ever found the first slide. Counting now turns the value into a number first, on every tier of the JavaScript engine. Then the slide strip had no height at all: the most common way of making a box hold its floated children (an invisible table-like box after them) was ignored. It works now too. The page now matches the reference browser.
No page can eat gigabytes any more
On six of the random sites 0.1.376 kept growing until it held between 2 and 22 GB: an encyclopedia, a tech review site, a wiki, a statistics office. Their scripts build and drop large amounts of linked data while they run, and that memory was only reclaimed once the script finished. Memory is now reclaimed while a long script runs, and a page that passes a quarter of the computer's memory is stopped with a message saying so, the way a browser ends a tab that runs out of memory. All six now settle at a few hundred MB. Two pages had causes of their own. A government site plays a video that the system decodes for us; every decoded frame of a stretch of video was kept, more than 8 GB. Now at most 96 MB of frames are kept and an idle video lets go of them: 8,151 MB at its peak before, 242 MB now. A phone company's page puts a page inside a frame that loads the same page again, which loaded itself again, and so on: 4,169 MB. A frame can no longer show a document its own parent already shows, and a page loads at most 128 frame documents (the console says why when it stops one): 448 MB now.
Animated images keep only what changes
An animated picture was kept as every one of its frames, fully decoded: a science magazine's front page held 161 MB of them. Most of a frame is the same as the one before it, so Floati now keeps only what changed from one frame to the next, packed, and rebuilds each frame as it is shown. Frames are also decoded one at a time instead of all at once, and an animation wider than the screen is kept at the screen's width, like a still photo. Every frame still comes back pixel for pixel. Still photos follow the same rule: a picture far wider than the window keeps only the pixels a screen can show.
A news site loads, and scripts see their images
Servers squeeze their reply headers with a fixed code table. Floati knew only the part of the table for plain letters and digits, so when a financial news site sent a less common character, the whole reply was refused and the page never loaded. The full table is in now, checked against the standard's own example. Its robot-check script then failed on a loop form Floati did not accept (a loop that stores each key into an array slot), which is now supported. Separately, a page's scripts now see the images Floati has already loaded as loaded, at their real size; before, a script asking for an image's size started a second download of it and read nothing until that finished.