Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Переходы между страницами сайта

Случайно наткнулся на несколько сайтов: Гитхаб, Гугл+, Фейсбук и ВКонтакте. Шустрые сайты. На их фоне другие сайты — неповоротливые гусеницы. Так получилось из-за того, что вышеперечисленные сайты активно используют History.API, суть которого в том, что из джса можно манипулировать урлом, без перезагрузки окна.

Вывод
Страницы современного сайта должны переключаться без перезагрузки окна браузера.

Передайте дизайнерам, пожалуйста, эту инфу, ну, чтобы они учли.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



30 коментарів

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

Якщо зайнятись комплексним рішенням проблеми, і зайнятись оптимізацією сайту, то будь який сайт буде швидко відкриватись.

как вы думаете зачем придумали хистори-апи? ведь, обновление отдельных частей странички было задолго до него

Автор хочет нам навязать свое клише. Без обид.

А быстры они не только из-за хистори.апи, но еще и потому, что там правильно настроенные сервера и их МНОГО :) И оптимизаций там много.

Правильно анимированный интерфейс «ускоряет» работу программы в несколько раз. Если у интерфейса хороший отклик (где надо прогрессы, где надо свистелки), то у пользователя уже не так много дискомфорта от «длительных» операций.

кхм... думаю, что для вас не секрет, что в клиент-серверном приложении три понятия «быстро». поэтому

Правильно анимированный интерфейс «ускоряет» работу программы в несколько раз
выглядит странновато. резкий диссонанс со второй частью сентенции, посвященной дискомфорту пользователя при ожидании. имхо, никакой красивый воркфлоу ожидания не перекроет тупизну приложения в комплексе.

что для вас не секрет, что в клиент-серверном приложении три понятия «быстро»

В общем секрет (буду благодарен за информацию :) ).
Я так понял имеется ввиду: клиент, сервер и передача?
Если да, то тут все просто:
— Тормоза сервера — это проблема в ДНК разработчика и/или в железе. Их можна контролировать: кеш, очереди, написать нормальный алгоритм (в конце концев) и тд.
— Тормоза передачи с клиента на сервер и обратно — контролировать практически не возможно.

— Тормоза клиента — зависят от его рабочей станции, и тут уже ничего не сделаешь. Понятно что код можна оптимизировать и тд, но если человек возьмет еще более слабый ноутбучек (или нетбучек), откопает ИЕ6, поставит каспера и тд.

Слово «ускоряет» я написал в кавычках, то есть имелось ввиду не абсолютная скорость (в миллисекундах), а ощущения пользователя. 1-2 секунды анимации — это дополнительное время для сервера и на передачу данных.

имхо, никакой красивый воркфлоу ожидания не перекроет тупизну приложения в комплексе.

Речь идет не о «тупизне в целом» (это ДНК и/или железо), а о «завтыках» (что так же не хорошо) и/или о вещах не особо зависящих от разработчика.

Если да, то тут все просто

круто, если для вас это всегда просто. для меня, например — сложно :)

с учетом множества совсем ненулевых рисков...

Тормоза сервера — это проблема в ДНК разработчика и/или в железе. Их можна контролировать: кеш, очереди, написать нормальный алгоритм (в конце концев) и тд.

а бизнес-логика? межсерверное взаимодействие, пессимистичность блокировок и т.д. не все так просто, имхо. если разрабатывали мульти-нодовую систему с распределенной архитектурой — там кэши и очереди всего один из инструментов и то — не главный. касательно железа — не могу не согласиться, но общая архитектура влияет сильно — узкие места не перекрываемые железом никто не отменял :)

Тормоза передачи с клиента на сервер и обратно — контролировать практически не возможно

хм... датацентр получше с каналом пошире и пошустрее, балансинг нагрузки, оптимизация протоколов, не?

Тормоза клиента — зависят от его рабочей станции, и тут уже ничего не сделаешь. Понятно что код можна оптимизировать и тд, но если человек возьмет еще более слабый ноутбучек (или нетбучек), откопает ИЕ6, поставит каспера и тд

собственно — сделаешь :) оптимизация, несколько видов лэйаута в зависимости от платформы/производительности

Речь идет не о «тупизне в целом» (это ДНК и/или железо), а о «завтыках» (что так же не хорошо) и/или о вещах не особо зависящих от разработчика.

Вещи не зависящие тоже не все умеют корректно обрабатывать :) Итого имеем «тупизну» и «завтыки», которые прямо зависят от разработчика + корректна обработка исключительных ситуаций, не зависящих от разработчика.

Везде можно руку приложить :)

а бизнес-логика? межс....

Я не говорю что разработка на стороне сервера — это понты. Это сложно, но оптимизация более контролируемая.
Снова же важный момент:

Если сервер тупит +3 секунды, например, — это можна скрить при помощи каких-то эффектов на клиенте (самое простое «крутилка»). Но тут важно другое: если крутилка появляется иногда — это нормально и не будет особо раздражать, но если при (!) любой операции — это уже хуже :)

хм... датацентр получше с каналом пошире и пошустрее, балансинг нагрузки, оптимизация протоколов, не?

А провайдеру клиента тоже оборудование будете тюнить? ;)

Кстати, всякие аджаксы (и хисториАПИ — которое можна использовать как доп кеш) вполне нормально могут помочь уменьшить и объемы трафика.

оптимизация, несколько видов лэйаута в зависимости от платформы/производительности

Риск получить 100500 версий кода, их на практике и так под браузеры и под ИЕ6, ИЕ7, ИЕ8, ИЕ9. Вот только как вы будете определять что у пользователя установлен антивирус и что он зашел не с игровой машины от алианвэер, а с старенького ноута?

Это сложно, но оптимизация более контролируемая.

ой-вэээй... боюсь, что не всегда это так :)

А провайдеру клиента тоже оборудование будете тюнить? ;)

хм... компактизация протокола и уменьшение количества запросов снижает нагрузку на каналы на маршруте в целом и конечного пользователя — в частности, разве нет? я не только про датацентр писал, вы вырвали из контекста :)

Риск получить 100500 версий кода, их на практике и так под браузеры и под ИЕ6, ИЕ7, ИЕ8, ИЕ9.

перефразируя: версий бояться — в софтварь девелопмент не ходить :) что страшного-то? и не будет их много при грамотном проектировании — сказки все это.

Вот только как вы будете определять что у пользователя установлен антивирус и что он зашел не с игровой машины от алианвэер, а с старенького ноута?

можно и определять, а можно дать выбрать пользователю комфортный вариант.

компактизация протокола и уменьшение количества запросов снижает нагрузку на каналы на маршруте в целом и конечного пользователя — в частности, разве нет?

Да. Только возвращаясь к теме хисториАПИ — они позволяют вместо передачи всей страницы, передавать куски (и частично их кешировать, особенно если представление формируется на клиенте) — то есть уменьшить обем передаваемых данных и ресурсы на формирование данных (!) в одном запросе (но это зависит от страницы и от архитектуры вцелом), при соизмеримом количестве запросов.

и не будет их много при грамотном проектировании — сказки все это

Вот тут бы поподробнее. Я не встречал ни одного веб-дева который бы ни разу не писал «if (IE)». Снова же интерфейсы под телефончики — это уже ветвление, как в плани внешнего вида, так и в плане производительности.

можно и определять, а можно дать выбрать пользователю комфортный вариант.

Поподробнее, пожалуйста. 2 интерфейса?

Да. Только возвращаясь к теме хисториАПИ — они позволяют вместо передачи всей страницы, передавать куски (и частично их кешировать, особенно если представление формируется на клиенте) — то есть уменьшить обем передаваемых данных и ресурсы на формирование данных (!) в одном запросе (но это зависит от страницы и от архитектуры вцелом), при соизмеримом количестве запросов.

если вы перечитаете весь трэд, то вы поймете, что дело не в History.API, так вы со мной ни о чем по данному пункту спорите :) я не против History.API, я против перекосов в проектировании :)

Вот тут бы поподробнее. Я не встречал ни одного веб-дева который бы ни разу не писал «if (IE)». Снова же интерфейсы под телефончики — это уже ветвление, как в плани внешнего вида, так и в плане производительности.

версий кода в целом много не будет — будет больше версий компонентов кода, которые требуют кроссбраузерной оптимизации. компонент — штука реюзабельная и часто тоже гранулярная.

Поподробнее, пожалуйста. 2 интерфейса?

почему нет? раз уж пошла диверсификация по платформам и нужен охват целевой аудитории и возможность кроссплатформенной работы — придется с этим что-то делать :) разные лэйауты для разных платформ, вариации лэйаута или компонентов лэйаута в рамках одной платформы под разную производительность и т.д.

если вы перечитаете весь трэд, то вы поймете, что дело не в History.API, так вы со мной ни о чем по данному пункту спорите

Это был больше аргумент вдогонку к «Если сервер тупит +3 секунды».

версий кода в целом много не будет — будет больше версий компонентов кода

Согласен, ступил, я так же именл ввыду версии компонента системы (с термином «компонент кода» не знаком, если я вас не правильно понял, уж простите). И тут важно другое:

разные лэйауты для разных платформ, вариации лэйаута или компонентов лэйаута в рамках одной платформы под разную производительность и т.д

Проблема в том что лэйаут — это не только разметка, это еще и часть (иногд большая часть) клиентского кода, написанного на джаваскрипте, кода который зависит от браузера и очень плохо покрывается тестами — это довольно серьезно увеличивает время тестирования.
Но мы сново же отклоняемся от того с чего начали:

Оптимизация интерфейса и всякие «перделки», так или иначе, позволят закрыть дирки не только в самом интерфейсе, но и в серверной части и пробелы в организации передачи данных.

Согласен, ступил, я так же именл ввыду версии компонента системы (с термином «компонент кода» не знаком, если я вас не правильно понял, уж простите).

собственно, вы начали оперировать понятием «код», я его подхватил. обычно я другую терминологию использую :)

Проблема в том что лэйаут — это не только разметка, это еще и часть (иногд большая часть) клиентского кода, написанного на джаваскрипте, кода который зависит от браузера и очень плохо покрывается тестами — это довольно серьезно увеличивает время тестирования.

собственно, термин interface layout ввели для обособления контейнера, который обеспечивает среду исполнения для контролов, что подразумевает, что layout это не только визуализация, но и некая поведенческая модель.

код на JS плохо покрывается тестами, а вот контролы и их поведение, которые он реализует — покрывается. но, если посчитали стоимость внедрения автоматизации функционального тестирования и поняли, что «не торт» по цене внедрения и поддержки — что тогда остается? правильно — тестировать вручную. дорого? дорого, а кто спорит. а цена проекта в комплексе дороже или дешевле цены вопроса невыполнения обязательств по качеству — недополученная прямая и косвенная прибыль, репутационные издержки, реализованные риски пипл-менеджмента?

Но мы сново же отклоняемся от того с чего начали:

Оптимизация интерфейса и всякие «перделки», так или иначе, позволят закрыть дирки не только в самом интерфейсе, но и в серверной части и пробелы в организации передачи данных.

я категорически утверждаю — нет, не закроют. цель интерфейса — не закрывать дырки. обработать корректно исключение в дружественной форме — да, но если компонент системы начинает работать вместо кого-то — это костыль, который чем дальше в лес, тем дороже.

хочу дать пищу для размышлений

Коментар порушує правила спільноти і видалений модераторами.

По поводу оптимизаций и серверов.
Для простоты берем словари многосерверного и супер-оптимизированного Яндекса, более чем сопоставимого со всеми представленными выше сайтами. Клац lingvo.yandex.ru/...ь/по-английски

Переключаем язык в правой колонке. Наблюдаем за тем как вся страница мигает, загружаются всякие каунтеры и прочая фигня, которую достаточно один раз загрузить. Сравниваем это поведение с, например, Гугл+

Google+ is Built Using Tools You Can Use Too: Closure, Java Servlets, JavaScript, BigTable, Colossus, Quick Turnaround
highscalability.com/...e-java-ser.html

А как же SEO? Контент проектам так точно делать не стоит.

Путаешь хистори-апи с хеш-тегом. Хистори-апи меняет урл как и при обычном переходе при клике на ссылку. Если открыть эту же ссылку в другом окне, сервер-сайд все правильно отрендерит. Сео не страдает.

Только, насколько я помню, у них одна «рабочая область» (фактически перегружается 1 контейнер), весь секс начинается когда надо перегружать несколько областей (интерфейсы бизнес-приложений часто бывают довольно сложными) :)

да, все верно, в архитектуру нужно заложить механизм — это технологическое усложнение, зато пользователь в выигрыше.

Вопрос больше не в архитектуре, а в интерфейсе. Например: 3 взаимосвязанные области, то есть при беке/нексте надо обновлять 3 области (+ один заголовок). Технически задача решаемая (и не очень сложно), но код становится намного более тесно связан, теряется простота поддержки. Более весомая проблема что проекту более 7 лет, оттуда же и довольно загруженный интерфейс.

связи кода разруливаются. observer + покрытие автоматизированными тестами. тем более, если проекту 7 лет и навертели много всего — сам бог велел. проект не умер — значит нужен, если нужен — цена вопроса стабильности каждой новой версии стала выше. селениум с плагинами вам в руки :)

селениум с плагинами вам в руки :)

Уже давно есть :)

+100500, осталось связность поковырять и скоро «щастье»?

осталось связность поковырять и скоро «щастье»

Последние пол-года «выковыривал» на 2 страницах, а страниц далеко не 3 :) но это уже другая история.

тогда может не надо выковыривать, раз так дорого? ну попадете на тестирование, но зато вы сделаете что-то более оптимальное по цена/качество? :)

Советы по дизайну, которые начинаются со слов «Должны» и «Всегда» редко бывают ценными. :)

Есть несколько слов, которые никогда не стоит употреблять в бизнесе. Нет, не те, что вы подумали! Это вполне цензурные слова — нужно (need), обязан (must), не могу (can’t), легко (easy), только (just), единственный (only), быстро (fast). Они — как красные флаги, преграждающие путь к здоровому общению. Они провоцируют враждебные отношения, торпедируют искренние обсуждения и служат причиной задержки проектов.

© Rework

«Ководство» в таком стиле написано, дизайнеры любят когда им указывают :)

Підписатись на коментарі