Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет

@Pipe({ name: 'fullName' })
export class FullName implements PipeTransform {
  transform(value: any): string {
    return value.firstName, value.lastName].filter(el => !!el).join(' ');
  }
}

<img [src]="userService.getUserAvatar(user.id)">

Не увидел важной для себя детали- ссылки на проверку для мобильных приложений.
google конечно поможет, но по готовой ссылке было бы удобнее
Эта похоже:
https://search.google.com/test/mobile-friendly

Для ленивых так же существует Mozilla SSL Configuration Generator, который позволяет выбрать версию веб-сервера и OpenSSL, и в зависимости от их версий подбирает оптимальные параметры.

Всем привет. Я собственно ответственный за техническую сертификацию в FIDO. Буду рад ответить на любые вопросы

Так же хочу заметить что у меня есть слайды по WebAuthn http://slides.com/herrjemand/webauthn-isig

Так же у нас есть воршоп, вот слайды https://slides.com/fidoalliance/jan-2018-fido-seminar-webauthn-tutorial#/

И собственно демо к воркшопу
https://github.com/fido-alliance/webauthn-demo

Я правильно понимаю, что Ваш маппер НЕ поддерживает:

• маппинг вложенных свойств
• маппинг коллекций
• маппинг на существующий объект (обновление)
• генерацию проекций для IQueryable<T>

И при этом (судя по Вашим бенчмаркам) всего на 10% бытрее того же Mapster, который все это умеет?

Еще было бы неплохо сравнить с EmitMapper.

А для ускорения маппинга вместо Expression.Compile можно использовать FastExpressionCompiler.

Суть проекта в компиляции expression tree напрямую, без создания анонимной assembly для запуска в песочнице (как это делает Expression.Compile).

Рёбя, немного не в кассу, но хочу поделиться, как я немного обуздал проблему производительности в Ионике 2 на iOS устройствах. На отдельный хабрапост данный текст явно не тянет, так что оставляю его тут в камменте, не пропадать же знаниям.

Так вот. Скроллинг для списков >= 100 элементов неприятно тормозил. Тормоза были двух типов:

1. Небольшая задержка при начале скроллинга
2. Сам скроллинг работал медленнее в сравнении с нативным

Решения:

1. Оказалось что событие onTouchStart (да и вообще любое событие) вызывает перерисовку элементов списка, выполняемого директивой ngFor. Для того чтоб этой перерисовки не было можно поместить код с ngFor в отдельный компонент, а к компоненту применить changeDetection: ChangeDetectionStrategy.OnPush. Как показала практика, changeDetection: ChangeDetectionStrategy.OnPush — довольно неплохое решение для многих проблем производительности в Angular 2. Вот тут подробнее описано как его готовить и с чем его едят. Там есть нью-ансы, рекомендую прочитать перед тем как юзать его на всех компонентах.
2. WKWebView — ответ на многие вопросы производительности в iOS устройствах. Подробнее тут: http://blog.ionic.io/cordova-ios-performance-improvements-drop-in-speed-with-wkwebview/. Кстати он решает не только вопросы производительности но и проблемы использования современных CSS3 свистелок. НО! тут есть подводный камень, а именно CORS. Если ваш сервер не умеет отдавать access-control-allow-origin хедер, то о замечательном WKWebView можно забыть.

P.S. А автору спасибо за статью, всё по делу.

Application Cache является устаревшей технологией и, скорее всего, будет со временем удалена поддержка сего в браузерах. Service Worker является ее заменой. localStorage для чего-то более-менее простого, для более сложных вещей — IndexedDB.