The "Appearance" => "Customize fonts" subpage renders slowly due to the number of <option> elements to add to the DOM (400 x 4 on my machine; depends on installed fonts).

Creating this page takes long enough that the expand animation drops most or all of its frames -- the page starts to fade in in-place, and the section immediately expands once the <select>s have been built.

The canonical fix is to set initial-count on dom-repeat. 10 would probably be a good trade-off between performance and latency. https://www.polymer-project.org/1.0/docs/api/dom-repeat

But settings-dropdown-menu expects all its items to be rendered in one chunk. It schedules an async task when its |items| property changes which either updates the <select> to the pref's value, or shows a special "Custom" value if the pref's value isn't found in the options list.

https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/controls/settings_dropdown_menu.js?type=cs&q=file:settings_dropdown_menu%5C.js+this%5C.async&l=100

Thus, if the dom-repeat renders asynchronously in chunks, the settings-dropdown-menu may come up with an invalid option index (because the pref value's option in the menu's |items| array doesn't correspond to a stamped <option> yet). This results in the <settings-dropdown-menu> showing the first option in the list, instead of the pref value.

I haven't found a "items-finished-rendering" type of event on dom-repeat. We could listen to dom-change, but that seems gratuitous.