Comments 13
Вам в номинацию вредных переводов. Куда делось minify javascript & css и почему вы всё сокращаете? Сократить можно объём, можно количество, а вы просто сокращаете, как дробь.
В принципе инфографика в данном случае (это уже претенции не к переводчикам) просто детская, в источнике developer.yahoo.com/performance/rules.html больше ценной информации.
В принципе инфографика в данном случае (это уже претенции не к переводчикам) просто детская, в источнике developer.yahoo.com/performance/rules.html больше ценной информации.
Используйте GET для AJAX запросовСомнительная рекомендация. Может привести к серьёзным проблемам с безопасностью.
Безопасность полностью зависит от реализации, например у gmail все параметры для AJAX передает в url’е, ну и проблем с безопасностью у них нет. А польза от этого в том что при POST запросе браузер посылает вначале заголовки, а потом POST данные, а при GET все помещается в заголовках.
Только что проверил в том же GMail операция удаления письма, отправляется AJAX запрос типа POST i.imm.io/1gAr0.png Это раз.
Во-вторых по поводу безопасности. Вот представьте, что у вас операция удаления объекта через GET вызывается x.com/?id=21&action=delete. Тогда злоумышленнику достаточно встроить на странице своего сайта img src=http://x.com/?id=21&action=delete и пользователь зайдя на эту страницу сам того не ведая выполнит эту операцию удаления. Можно конечно подписывать каждый GET запрос уникальной подписью, но это те ещё заморочки.
Как правило процент пользовательских AJAX запросов крайне мал по сравнению со всеми остальными < 5%. За счёт малого размера время выполнения этих запросов в основном зависит от времени обработки запроса сервером, а не от времени пересылки. Использование GET даёт выигрыш в размере чуть больше чем пинг, т.е. 100-200мс. Думаете пользователь почувствует разницу в 200мс? Думаете веб-сервер почувствует разницу в нагрузке при переходе на GET? Я лично очень в этом сомневаюсь.
Во-вторых по поводу безопасности. Вот представьте, что у вас операция удаления объекта через GET вызывается x.com/?id=21&action=delete. Тогда злоумышленнику достаточно встроить на странице своего сайта img src=http://x.com/?id=21&action=delete и пользователь зайдя на эту страницу сам того не ведая выполнит эту операцию удаления. Можно конечно подписывать каждый GET запрос уникальной подписью, но это те ещё заморочки.
Как правило процент пользовательских AJAX запросов крайне мал по сравнению со всеми остальными < 5%. За счёт малого размера время выполнения этих запросов в основном зависит от времени обработки запроса сервером, а не от времени пересылки. Использование GET даёт выигрыш в размере чуть больше чем пинг, т.е. 100-200мс. Думаете пользователь почувствует разницу в 200мс? Думаете веб-сервер почувствует разницу в нагрузке при переходе на GET? Я лично очень в этом сомневаюсь.
Да пост, но при чтении все параметры передаются в url’е, и POST пустой. При удалении в посте что то передается, возможно из-за описанного вами. Имхо запросы на чтение все же чаще приходят чем запросы на модификацию. Это все-таки перевод рекомендаций yahoo, поэтому не буду с вами спорить, у самого yahoo как-то все по разному сделано, что-то GET’ом что-то постом. Предлагаю считать, что запросы на чтение с AJAX лучше делать через GET, а на модификацию через POST.
Тут практически все рекомендации дают выигрыш меньше 100 мс, я бы оценил конкретно эту в 20-30 мс. Но сделав 10-15 исправлений, можно получить уже 500 мс, а это много. Уверяю вас, пользователи чувствуют разницу в 200 мс, если у вас конечно странички грузятся секунду не 15. Если время ответа сервера 3-5-10 секунд, то вам надо сервером заниматься, а не интерфейсом.
Тут практически все рекомендации дают выигрыш меньше 100 мс, я бы оценил конкретно эту в 20-30 мс. Но сделав 10-15 исправлений, можно получить уже 500 мс, а это много. Уверяю вас, пользователи чувствуют разницу в 200 мс, если у вас конечно странички грузятся секунду не 15. Если время ответа сервера 3-5-10 секунд, то вам надо сервером заниматься, а не интерфейсом.
Вот везде читаю «Помещайте JavaScript» внизу. С одной стороны да — загрузится страница, а потом javascript. Но! Отображение страницы начинается параллельно её загрузке и после загрузки начинают загружаться скрипты, которые внизу. Т.о. мы имеем задержку между отображением страницы и началом выполнения скриптов. Но часто js нужен уже по завершению загрузки страницы, так может лучше разместить загрузку javascript вверху, а вот исполнение скриптов по инициализации dom? Т.е. к моменту окончания отрисовки страницы скрипты уже загружены и просятся в бой! А вообще современные браузеры давно уже загружают параллельно и html и скрипты.
Конечно загружают. Но количество параллельно загружаемых объектов ограничено, по спецификации HTTP/1.1 2мя потоками на домен, в реальности побольше. И разница в основном в том, каким в очередь попадет скрипт, лучше вначале грузить css, потом картинки, потом скрипты, потому что первые 2 типа элемента формируют внешний вид страницы и визуально ускоряют загрузку страницы, особенно актуально если скриптов много, они большие, и не перестраивают DOM после загрузки.
В современных сайтах в визуальном представлении страницы все в большей части участвуют скрипты. В общем советы не правильно позиционируются как общие для всех сайтов, а на деле нужно исходить из задачи каждого отдельного сайта и то, что хорошо для одного сайта не лучшим образом скажется для другого.
Друзья, если взялись за перевод, так не халтурьте. «Компоненты постзагрузки» — что? Использовать? Избегать? В оригинале «Preload Components» по смыслу означает «загружайте заранее». То же и про «post-load components».
«GZIP компоненты» — что? По-русски будет «используйте gzip».
«GZIP компоненты» — что? По-русски будет «используйте gzip».
Sign up to leave a comment.
Лучшие приёмы для увеличения скорости вашего веб-сайта