Черга, яку тримало одне з’єднання

Де були байти

Воркер (/sw.js) займав 4 005 байтів стиснутого з 4 096 у бюджеті. На наступне виправлення лишався 91 байт. Перш ніж підіймати межу, я поміряв, з чого він складається. Код важив 3 329 байтів, переліки файлів і рядки для читача, які вписує збірка, 734. Коментарі збірка вже викидала, а відступи на початку рядків лишала, і лише вони важили 145 байтів.

Мініфікатор дав би більше, до 650 байтів, але тоді опублікований воркер перестав би читатися по рядках. Тести шукають у ньому const NETWORK_WAIT = 10000;, validate:public читає рядок зі збіркою як JSON, і я сам перевіряю так воркер у проді. Тому збірка тепер знімає лише відступи, а шаблон із літералом у зворотних лапках на кілька рядків вона відхилить, бо там відступи були б частиною тексту. Я пробував іще звести два однакові цикли в одну функцію, але так вийшло на 23 байти більше: gzip і так стискає повтори. Разом із виправленнями нижче воркер важить 3 868 байтів, лишається 228, і межу підіймати не довелося.

Одне з’єднання тримало всю чергу

Сторінки відкладених записів і сторінку, на яку читач прийшов першим візитом, воркер завантажує сам, у черзі, по одному повідомленню сторінки за раз. Межі очікування там не було. Якби мережа по одній такій сторінці не відповіла й не обірвалася, наступні зірочки й сторінки стояли б за нею, доки браузер не зупинить воркер: у Chromium через п’ять хвилин.

Спершу тести. Перший ставить зірочку на запис, чия сторінка ніколи не відповідає, потім ще одну. Другий робить перший візит одразу на сторінку запису, яку воркер потім не може завантажити, і ставить зірочку. Щоб не чекати справжню межу, тест дає воркеру дві секунди замість неї: код той самий, змінюється лише число. На старому коді обидва тести впали: друга зірочка не збереглася.

Виправлення має дві частини. Ці запити тепер мають ту саму межу, що й файли оболонки. Крім того, відкладений запис, який не прийшов, більше не зупиняє решти: раніше помилка на одній сторінці обривала весь перелік, і запис, відкладений після неї, не зберігався, поки вона не прийде. Тепер цю сторінку буде спробувано знову з наступним повідомленням, а інші зберігаються одразу.

Сторінка без копії

Коли мережа не відповідає, а копії сторінки немає, воркер не показує заглушку, а чекає далі: так 27.09 вирішив «6 в 1». Досі тесту на це не було, бо, здавалося, для нього треба чекати всі 10 секунд. Новий тест дає воркеру одну секунду і пропускає сторінку через три. Приходить сама сторінка, а не заглушка й не рядок про копію, і вона зберігається, як будь-яка відкрита. На старому коді тест теж пройшов: поведінка вже була, тепер її закріплено тестом.

Firefox і WebKit

Firefox і WebKit у Playwright знайшлися на цьому комп’ютері, тож завислі встановлення я поміряв і в них. Стандартний тест там не підходить: у WebKit і Firefox context.route не бачить запитів воркера, а в WebKit ще й падає навігація в офлайні. Тому я написав окрему пробу з маленьким проксі перед сайтом, який на один файл не відповідає.

WebKit сам обриває такий запит приблизно за 60 секунд, і воркер прибирає за собою. Firefox за ті самі приблизно 60 секунд зупиняє воркер, і тоді половина кешу нової збірки лишається, як лишалася в Chromium до попереднього проходу. Наша межа тоді була якраз 60 секунд і змагалася з Firefox: в одному прогоні з трьох він устиг першим. Я спитав, і «6 в 1» вибрав 45 секунд. Цього вистачає, щоб найбільший файл оболонки прийшов навіть повільною мобільною мережею. При 45 секундах Firefox прибрав за собою в усіх трьох прогонах, WebKit теж.

Що не перевірено

Тести пройшли тільки в Chromium: pwa.spec.ts тричі поспіль, плюс verify:code. Хвилин GitHub Actions до 1 жовтня немає, тож CI цього проходу не бачив. Firefox перевірено в старішій збірці, ніж чекає Playwright (ревізія 1538 замість 1543), бо встановлювати браузери без потреби я не став. Firefox і WebKit бачили лише зависле встановлення, а не черговість зірочок. Справжні Android, iOS і Safari на macOS не перевірено.