Page Size - How big is too big?

[NickMNS]

I am rebuilding one of my sites and I currently have some long pages, and these pages have second page associated with it, that has even more content. The second pages content is border line thin. Google has been sending traffic to them, but not as much as the main page. This second pages was created because I felt that when I created it users needed somewhere to click to after consuming the first "main" page, and I didn't have the capabilities at the time to deliver any other meaningful content.

Things have changed and I am now redesigning things, I now have the capability to provide some really compelling content after the main page so I want to consolidate the two pages and focus the user on the new content. But this consolidation will create one large pages, in excess of 100kb.

The main page provides information about a topic, the first section provides a description of the topic and then I have sub-sections going down the page addressing different aspects of the topic. The sub-sections are put into context by the description at the top. Each sub-section could stand on its own, that is be its own page. Like my "second" page, the content is there but it would tend more towards the thin end of the spectrum. Users searching for those specific details on the topic will find what they are looking for on the page, but I question whether the user would be willing to click through to another page to consume the rest of the offering. Whereas on the single page the users sees it all and is more likely to consume it all.

I should mention here that my intention is to create the pages with AMP and I am seriously considering adding PWA functionalities.

What are my options?
- Create one large page, static page.
- Create one main-page and somehow paginate each sub-section.
- Use a single-page-app desgin pattern such that each sub-section is added as the user scrolls or clicks show more, each sub-section would have its on url (using pushState). This would be difficult to implement with AMP or one could simply forgo AMP.

[engine]

How long is a piece of string!

Build it for your site visitors, not for yourself, if you get my drift. Compromise, by all means, but do consider your audience, and the format they's be using. If it's predominantly mobile, I wouldn't say that 100kb is large, and if you're going AMP, it should reasonably lightweight.

Eventually, people will get bored scrolling.

Of course the other thing is how much content you need to give your audience to keep them engaged. The other thing is, are y9ou serving ads on it, or expecting roi through some kind of sign-up to a newsletter, a product, or a service?

[NickMNS]

Build it for your site visitors, not for yourself, if you get my drift.

This is precisely why I am posting the question. I would like to know whats other are doing? What are the norms, if there are any?

Based on the current static-prototype the page is 7000px tall on mobile screen(360 width).

The question is, what is worse scrolling or clicking? Scrolling is certainly better on a short page, but at some point scrolling becomes annoying and a click becomes preferable.

I feel that users probably prefer clicking when they are fully engaged and know what to expect. But I also feel that a click is a big ask, and users will likely leave instead of clicking to the next page. Simply scrolling, is more of the same. So the user may discover something they would otherwise have clicked away from.

The site is purely informational and is monetized with ads.

Without going into specifics a good analogy for the design pattern is a profile page for an athlete like a baseball player. The top of the page has the description of the player, and then there are sub-sections describing specific stats about the player. Like a section for batting, and then another for pitching. It seems to me that a page only for a player's pitching stats could work but without the player's profile it would seem a little odd. And, a user checking pitching stats may not be interested enough to click to another page to see the batting stats. But the user probably would find the batting stats interesting if they were to see them on the page.

Writing this makes me think that I could have a page with the profile at the top and then buttons for each sub-section. A click on the button would add the sub-section, a click of the next sub-section would remove the previous sub-section and add the next. Each button would generate a new URL (pushState).
So profile page url would be: example.com/player-profile
sub-sect-1 url would be: example.com/player-profile/sub1
sub-sect-2 url would be: example.com/player-profile/sub2

Then if Google sends the user to example.com/player-profile/sub1 the user gets the profile and sub1 and then they can click on any other subsection.

Now what about duplicate content? How will Google interpret the fact that the profile will appear on 5 different pages (1 profile + 4 subs)?

[lucy24]

100k of what? The HTML alone? How big is the entire page load, including ads? For comparison purposes: Depending on how much interlinking you’ve got, a single page of a printed book, exclusive of illustrations, runs 2-3k. Do your readers want the whole book, or just one chapter?

Take a closer look at navigation. Mobiles by their nature aren’t as navigation-friendly as desktops, especially when it comes to scrolling. In particular, make sure there is always a way back to the top, and then ways to home in on a specific part of the page moving in the other direction.

You may or may not be able to find out whether search engines are sending people directly to a mid-page fragment. If it happens a lot, it’s a hint that too much information is collected on a single page; “back to where I started” may not be the same as “back to top”. If visitors often close the page before the whole thing has loaded up--I see this most often with mobiles--I would again take it as a hint that the information didn’t all belong on the same page. (Or that the search engine goofed, but that’s a different issue.)