Почему простой сайт разбивается на мобильные устройства (как минимум, на iOS Safari и Chrome)?

Ответ 1

Думаю, я исправил это!

Проблема, как и предполагалось, была рендеринг/роспись, вызванная макетом CSS. При размере телефона я скрывал содержимое каждой записи до ее выбора; и метод, который я использовал, чтобы скрыть их, и удалить любую трассировку из макета, включил position: absolute. Я изначально не использовал display: none из-за типичных опасений по поводу того, что вы не видите контент, но держите его там, для разных читателей и причин. Я отбросил эти проблемы и изменил компоновку, чтобы записи были скрыты с помощью display: none и показаны с помощью display: block - и это, похоже, устранило сбой.

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

Что заставило меня задуматься, это было ответом на другой связанный с ним вопрос, связанный выше: @tea_totaler: fooobar.com/questions/164556/.... В нем говорится:

Что мне очень помогает, так это сохранить все, что не отображается в данный момент под дисплеем: none. Это может показаться примитивным, но на самом деле делает трюк. Это простой способ сказать рендереру браузера, что вам не нужен этот элемент в это время, и, следовательно, освобождает память. Это позволяет создавать вертикальные скроллеры длиной в милю с различными видами 3D-эффектов, пока вы скрываете элементы, которые вы не используете в настоящее время.

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

Что-то учитывать, хотя, если вы хотите скрыть элемент: требуется рендеринг/память.

Ответ 2

На моем сайте это было вызвано элементами с свойством css -webkit-backface-visibility: hidden

удаление этого свойства устранено все сбои!

см. iOS: несколько разделов с -webkit-backface-visibility: скрытый браузер сбоев при масштабировании

Ответ 3

Я проверил аудит с Chrome на сайте. Он предложил следующее:

Удалить неиспользуемые правила CSS (44)
44 правила (10%) CSS, которые не используются текущей страницей.
css-built.min.css: 10% не используется текущей страницей.

    audio, canvas, video  
    audio:not([controls])  
    [hidden]  
    abbr[title]  
    dfn  
    hr  
    mark  
    q  
    sub, sup  
    sup  
    sub  
    svg:not(:root)  
    figure  
    fieldset  
    legend  
    button[disabled], html input[disabled]  
    input[type=checkbox], input[type=radio]  
    input[type=search]  
    input[type=search]::-webkit-search-cancel-button, input[type=search]::-webkit-search-decoration  
    textarea  
    table  
    .older-docs  
    .older-docs>li  
    .older-docs>li:not(:last-child):after  
    *, :before, :after  
    fieldset  
    textarea  
    :not(pre)>code[class*=language-], pre[class*=language-]  
    :not(pre)>code[class*=language-]  
    .namespace  
    .token.regex, .token.important  
    .token.important  
    .older-docs  
    .changelog dt  
    .changelog>dt  
    .changelog>dt:after  
    .changelog>dd  
    .changelog-i-list  
    :target>.entry-body  
    .sub--h  
    .example--css.is-active  
    .preload .help-content-c  
    .help-content-c.is-active  
    .help-content.is-active  

Диспетчер задач в Chrome показывает, что страница занимает около 2-х суммарной памяти, чем другие сайты, такие как stackoverflow и dropbox. Я бы рекомендовал разделить функции на отдельные страницы вместо одной длинной страницы. Разделив функции, это улучшит эффективность сервера и время загрузки браузера и использование памяти. На каждой странице будет меньше JavaScript и CSS, и с сервера будет отправлено меньшее количество данных. Наличие всех функций на домашней странице неэффективно. Например, если пользователю нужно было только посмотреть, как создать метку значка шрифта, им придется загружать другие разделы страницы, которые не нужны и занимают память.

Ответ 4

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

1.) Использование data-url для рендеринга фонового изображения, например здесь

.github,.source {
background-image: url("data:image/svg+xml;charset=US-ASCII,%3Csvg%20width%3D%22100%22%20height%3D%22100%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cpath%20d%3D%22M85.714%2050q0%2014.007-8.175%2025.195t-21.122%2015.485q-1.507.279-2.204-.391t-.698-1.674v-11.775q0-5.413-2.902-7.924%203.181-.335%205.72-1.004t5.246-2.176%204.52-3.711%202.958-5.859%201.144-8.398q0-6.752-4.408-11.496%202.065-5.078-.446-11.384-1.563-.502-4.52.614t-5.134%202.455l-2.121%201.339q-5.19-1.451-10.714-1.451t-10.714%201.451q-.893-.614-2.372-1.507t-4.66-2.148-4.799-.753q-2.455%206.306-.391%2011.384-4.408%204.743-4.408%2011.496%200%204.743%201.144%208.371t2.93%205.859%204.492%203.739%205.246%202.176%205.72%201.004q-2.232%202.009-2.734%205.748-1.172.558-2.511.837t-3.181.279-3.655-1.2-3.097-3.488q-1.06-1.786-2.706-2.902t-2.762-1.339l-1.116-.167q-1.172%200-1.618.251t-.279.642.502.781.725.67l.391.279q1.228.558%202.427%202.121t1.758%202.846l.558%201.283q.725%202.121%202.455%203.432t3.739%201.674%203.878.391%203.097-.195l1.283-.223q0%202.121.028%204.967t.028%203.013q0%201.004-.725%201.674t-2.232.391q-12.946-4.297-21.122-15.485t-8.175-25.195q0-11.663%205.748-21.512t15.597-15.597%2021.512-5.748%2021.512%205.748%2015.597%2015.597%205.748%2021.512z%22%2F%3E%3C%2Fsvg%3E");
background-repeat: no-repeat;
}

2.) Кроме того, виновником может быть -webkit-переход. Подробнее читайте здесь fooobar.com/questions/164556/...

Ответ 5

В вашей разметке HTML есть некоторые ошибки (например, тег div внутри тега h1), которые необходимо устранить, прежде чем пытаться проанализировать сбой.

Я предлагаю вам запустить его через валидатор HTML, например http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

div внутри h1, по-видимому, вызвал каскад ошибок, которые валидатор должен был подавить, чтобы продолжить.

Когда у меня проблемы с браузером, проверка HTML всегда является моим первым шагом. Затем я пытаюсь понять, что может быть неправильным с javascript, если исправление HTML не помогло.

Ответ 6

Я просто прочитал этот пост и попробовал http://davidtheclark.github.io/scut/ на своем iPad. Chrome немедленно сбой, хотя иногда и коротко показывает домашнюю страницу. Safari отображает правильную домашнюю страницу и многие другие страницы, но нажатие левой кнопки "about > installation" приводит к сбою сразу (ну, как только она отображается ОК, но щелчок снова разбил ее). Все это довольно непротиворечиво.

Ошибки действительно связаны с LowMemory, и это процесс браузера, который использует большую часть памяти. Аварии происходят примерно на 150000 страницах (4KB/page? = > 600MB???).

Говоря, я боюсь, что у меня нет ответа на ваш вопрос. Надеюсь, это поможет хотя бы немного.

С уважением, /Sigiswald

Ответ 7

Удаление position: sticky; помогло мне и моим проблемам с сафари в мобильных устройствах. Не уверен, почему именно.

body:before{
    position:-webkit-sticky;
    position:sticky;
}