Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Website testing on mobile and small screens #57

Closed
2 of 6 tasks
fhemberger opened this issue Aug 30, 2015 · 11 comments
Closed
2 of 6 tasks

Website testing on mobile and small screens #57

fhemberger opened this issue Aug 30, 2015 · 11 comments
Labels
good first issue Issues for newcomers

Comments

@fhemberger
Copy link
Contributor

We need to test the website on small screens as well. This means browser tests (e.g. with Chrome's device mode), but also real browser tests on devices (Safari iOS, Chrome for Android, Opera Mobile).

  • Test overall website
  • Test site performance (Wifi, EDGE, 3G)
  • Check font size, margins, table- and blog layout
  • Adjust layout of main navigation
  • Adjust layout of sub-navigation
@fhemberger fhemberger added the good first issue Issues for newcomers label Aug 30, 2015
@rvagg
Copy link
Member

rvagg commented Aug 30, 2015

you have less than 2 days btw

@fhemberger
Copy link
Contributor Author

Aaaahhhhh! running around panicking

Okay, well. I guess this means we'll do this after the initial release.

@mikeal
Copy link
Contributor

mikeal commented Aug 30, 2015

@rvagg this is the biggest blocker we have right now nodejs/build#163 (comment) we need all the old node.js builds to show up in versions.

@evanlucas
Copy link
Contributor

Do we want/need to adjust the layout of the main navigation? If so, anything I can help with?

I am going through and checking each page to see if any alignments are off and things like that now.

@fhemberger
Copy link
Contributor Author

@evanlucas Adjusting the margin/padding should be fine, ne need for a hamburger menu, et. al.

@ddprrt
Copy link

ddprrt commented Aug 30, 2015

I did some performance tests on the current https://new.nodejs.org website.

Webpagetest

Using Cable connection, from Dulles. Click here for the results. Fully loaded under 1 second, Speed Index < 1000. Repeated view somewhere in the 400s. Excellent stats

Using Fast 3G: Click here for the results. Fully loaded under 3 seconds, speed Index ~2500. This is okay. The repeated view is again excellent. Your cache works wonders.

Using Edge: Click here for the results. Fully loaded in 16 seconds, Start render at 14 seconds. This is a bummer.

Looking at the waterfall diagram (especially of the Edge render), we can easily define the culprits: Blocking CSS from three files. Solutions:

  • We could go full critical and inline the critical CSS and asynchronously load the remaining styles. I made some tests if this would be feasible for the new page, but due to the unique design of the contents, we would need to run the critical CSS task for each and every page, which would lead to huge build times and possible memory leaks.
  • Webfonts are the biggest issue, as they take the longest We could drop the Google CDN for the fonts and asynchronously load webfonts on our own (Source Sans Pro is Open Source), much like SmashingMagazine does (using localFont), and store them in localStorage for the other pages. This should reduce the Start Render time for about 3-5 seconds on EDGE, giving the users already something to read (if you don't mind "Flash of unstyled text"). Also: Ansychronously load the prism styles or merge them with the existing one. I could come up with a PR for this by tomorrow. This would also help with images like those:

PageSpeed Insights

Solid Results for Desktop View. Again, they suggest for inlining Critical CSS and asynchronously load everything blocking. Mobile Scores are okay-ish.

Ruxit Web Check

I set up a WebCheck up until launch (They are not open, but you can see what it does here). This one records availability from Chicago, Frankfurt, London, Seattle, San Jose, Boston, Paris, Atlanta, New York and Dallas, and gives an average duration time for each of those locations (measures the window.onload event with each visit). The scores are excellent there and mirror the Cable test from WebpageTest

Suggestions

  1. For Launch, unblock the Webfont and prism syntax highlighting. (PR follows if wanted)
  2. For later, come up with a way to inline the Critical CSS, or refactor the CSS to make them inlineable as a whole (we did that with our https://blog.ruxit.com as the minified CSS just had about 3K)
  3. Cache the hell out of CSS, JS and SVG :D

@0zguner
Copy link

0zguner commented Aug 31, 2015

@fhemberger I can write automated tests for various cases like screen sizes, fonts etc. and performance in case you need it in future.

@Fishrock123
Copy link
Contributor

@fhemberger
Copy link
Contributor Author

@ddprrt Awesome, thanks Stefan! :D

  1. I think we can get rid of prism entirely, AFAIK it's only used here and maybe one or two deeply burrowed older blog posts.
  2. With this gone, there isn't much "critical" CSS left. Removing (for testing) the base64'ed linux foundation footer SVG and another image (we're dumping anyway), we end up with 6,6k CSS total.
  3. Caching will be handled by CloudFlare

So yes, a PR for unblocking Webfonts would be great.

@mzgnr That sounds interesting. I'm not sure if it makes sense to invest the time into writing those test right now, as so many things are still constantly changing at the moment. But once everything has settled, they could provide insights for performance budgets.

@mikeal
Copy link
Contributor

mikeal commented Oct 7, 2015

Are we good here or is there still only 1/5 done?

@fhemberger
Copy link
Contributor Author

I think there are still some CSS things left for fine-tuning. It would be nice if someone finds the time to check the site on mobile again (except for webfont issues).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Issues for newcomers
Projects
None yet
Development

No branches or pull requests

7 participants