Comments 6
То ли я еще не проснулся и тороможу, то ли статья - лютая нейронка без редактирования. А тема то интересная...
Идея любопытная, но я так понимаю работает, только если есть пулл страниц которые нужно открывать и они заранее известны (и если скорость там критична - их бы перевести на натив по возможности).
Так ещё и памяти кушает скорее всего немерянно (держать комплект открытых webView в мапе недёшево).
В таком сценарии интересно было бы копнуть в другую сторону - если ресурс который надо открыть контролируем мы, то попробовать подгрузить заранее js/css/картинки со всех страниц в кэш браузера, а дальше уже запрос ограничивать чисто страницей.
Js динамичный же. Можно чисто прогреть движок конечно, сильного ускорения обычно это не дает
Что вы подразумеваете? У вас импорты js файлов меняются в реальном времени в зависимости от окружения? Даже если и так - нет проблемы просто загрузить их все - не нейросетью же они на лету пишутся) Или у вас страница рендерится на клиенте (html собирается js-ом из ajax запросов без рендеринга на сервере для первого открытия)? Если так - то логичнее эту проблему сначала решить т.к. она тормоза у всех клиентов, включая настольных, вызывает.
Когда я последний раз изучал вопрос - самые долгие операции в загрузке страницы были пачки запросов ресурсов (из за пингов). Условно загрузка страницы 100мс, там пак из 20-30 файлов (css/js/шрифты/иконки/картинки), ещё 200мс на загрузку, и уже отрисовка - 40мс.
Вот выкинув второй этап (правильно настроив кэши) результат получается впечатляющий
Как ускорить WebView в Android и доказать это цифрами