У меня есть платформа Next.js. При обновлении загрузка страницы занимает около 6 секунд. Поэтому я занимался отладкой, чтобы выяснить, где была задержка, чтобы узнать, что я могу сделать, чтобы улучшить ее, и обнаружил, что время простоя составляет около 5 секунд.
По сути, согласно инструменту отладки производительности Chrome и Firefox, существует 5-секундный период простоя между загрузкой всего и началом рендеринга первой страницы.
Я следую всем передовым методам ускорения платформы, таким как запоминание компонентов, динамическая загрузка компонентов, которые не нужно отображать, пока пользователь не взаимодействует с ними, ...
Вот круговая диаграмма из инструмента Chrome Performance, которая показывает время простоя:
Я хотел выяснить, где это происходит, поэтому я добавил несколько журналов временной метки на каждом этапе (_app.js, index.js,...) и обнаружил, что между первым вызовом _app.js и первым вызовом index.js, лежит ожидание 5 секунд.
Поэтому я начал удалять компоненты (обертки, такие как провайдеры, ...) один за другим, чтобы выяснить, был ли один из них причиной, но ни один из них не повлиял на время простоя более чем на 2 мс, в то время как где-то уходит около 5000 мс.
Мой вопрос в том, есть ли способ узнать, что это за время простоя или почему приложение так долго ждет, чтобы начать рендеринг, или кто-нибудь знает, что я могу попытаться ускорить?
Редактировать:
Вот скриншот водопада, где показано время простоя: Между ними нет запроса, и никакой другой запрос не ожидает результата. Один заканчивается, ничего 5 секунд, потом начинается рендеринг.
@FINDarkside самый большой запрос на вкладке сети составляет 2 МБ, а в среднем едва достигает 300 байт. Кроме того, для загрузки индексной страницы вызывается только один запрос, и этот загружается менее чем за 100 мс.
Я имею в виду, что на вкладке сети также есть 5 секунд бездействия? Если да, я не думаю, что люди могут вам помочь без кода. Продолжайте удалять код до тех пор, пока он не перестанет происходить, и если он не удаляет код, до тех пор, пока кода не станет достаточно для размещения здесь.
@FINDarkside только что добавил скриншот водопада, на котором показано время простоя. Последний запрос перед простоем — это поиск аккаунта в firebase, тот, что после него — первый рендеринг компонента. Никаких промежуточных запросов, просто 5-секундное время ожидания
Наконец нашел причину. Я использую PersistGate из redux-persist, и, по-видимому, тайм-аут по умолчанию составляет 5 секунд. Уменьшение его до 2 секунд фактически изменило время простоя до 2 секунд вместо 5.
Это не оптимальное решение, так как есть риск, что состояние не будет готово через 2 секунды, поэтому я сейчас просматриваю разные библиотеки, но, по крайней мере, я знаю, откуда взялось время простоя.
Если кто-то еще столкнется с этим, и причина в PersistGate, вот что сработало для меня:
const config = {
key: "root",
storage: localForage,
timeout: 2000,
};
Другие вещи, которые я обнаружил во время своего исследования:
Посмотрите на вкладку сети в инструментах разработчика, чтобы увидеть, есть ли какой-то длительный запрос API или что-то еще.