Comments 6
Откладывание загрузки изображений до завершения загрузки страницы.
С помощью простенького «ванильного» JavaScript можно реализовать отложенную загрузку изображений, которые находятся ниже начального экрана, или необязательны для того, чтобы пользователи могли как можно раньше начать взаимодействовать со страницей.
В чём смысл ленивой загрузки изображений? если они не являются критическим ресурсом и ничего не блокируют сами по себе, где бы в документе они не находились…
Сделать фоновый градиент в соответстивии с цветами будущего загруженного изображения;
При сохранении в фотошопе отметить галочку progressive
И этого будет достаточно!
Ну или по крутому, сделать как на medium:
— создать маленькую заглушку (40px по ширине) будущей картинки
— перегнать в base64 и сделать фоном будущей картинки
— заблюрить через css фильтры
— поверх создать блок с нулевой прозрачностью, в который в фоне js-ом грузим оригинал картинки
— по событию load картинки, ставим прозрачность на еденицу и убираем блюр у фона
На мой взгляд, в этом есть смысл. Если на странице, скажем, 20 картинок, даже не больших, кб по 100 — это уже 2 метра трафика. На мобильном — очень даже ощутимо. И в этом случае было бы лучше сначала быстро загрузить первые пару экранов, а остальное оставить на потом. Возможно, вообще повесив начало их загрузки на событие прокрутки экрана. Думаю, это можете т не мало сэкономить. Не факт, что пользователь вообще до этих картинок дойдёт — чего их гонять туда сюда?
Кто скажет, что делать с вот этим вот знанием про 14кб?
Эт такое же, знание, как то, что процессор быстрее обращается по адресам в памяти, которые представляют из себя степень 2-ки или 4-ки или…
Другими словами, imho, если вы пишите диспетчер памяти, то учет подобной специфики поможет сделать ваш диспетчер на n% эффективней. А если пишете, домашнюю бухгалтерию, то учет этого только усложнит код, поэтому не стоит и заморачиваться. Так и тут, хотите выиграть миллисекунды, урезаете/компонуете используемые ресурсы до 14 Кб. Если есть и более приоритетные проблемы, то не стоит и заморачиваться.
Другими словами, imho, если вы пишите диспетчер памяти, то учет подобной специфики поможет сделать ваш диспетчер на n% эффективней. А если пишете, домашнюю бухгалтерию, то учет этого только усложнит код, поэтому не стоит и заморачиваться. Так и тут, хотите выиграть миллисекунды, урезаете/компонуете используемые ресурсы до 14 Кб. Если есть и более приоритетные проблемы, то не стоит и заморачиваться.
Спасибо, очень хорошая статья. В последнем примере со скриптами modules, analytics и modernizr будет 3rtt на их получение
Sign up to leave a comment.
Оптимизация фронтенда под браузеры