Friday, October 16, 2020

What are core web vitals that affect Ranking - Part 1



Back in early May, Google introduced Core Web Vitals, a set of metrics designed to measure the quality of a website’s user experience. These metrics are related to page load time, interactivity and stability.


Now, Google has announced that they will combine Core Web Vitals with other factors such as mobile-friendliness, website security and the presence of intrusive interstitials to create a comprehensive evaluation of a page’s user experience.


This evaluation will also be incorporated into Google’s search algorithm, meaning Core Web Vitals will be used as a ranking factor.


What are Core Web Vitals?


According to Google, Core Web Vitals "measure dimensions of web usability such as load time, interactivity, and the stability of content as it loads (so you don’t accidentally tap that button when it shifts under your finger - how annoying!)."


Core Web Vitals are made up of 3 metrics:

Largest Contentful Paint (LCP) measures how long it takes a page to load and display the main page content. Aim for an LCP of 2.5 seconds or faster.


First Input Delay (FID) measures how long a user has to wait to interact with a page. A "good" FID is 100 milliseconds or less.



Cumulative Layout Shift (CLS) is the evaluation of how stable a page is as it loads. It measures how much the layout of a page shifts as it loads. Ideally, a page’s CLS should be no more than 0.1.


It’s worth noting, however, that the metrics scored in Core Web Vitals can shift and change as the web evolves. In fact, Google has said they anticipate incorporating more page experience factors into their ranking factors on a "yearly basis" as user expectations change.


How to use Core Web Vitals for your SEO


While the initial reaction to a new Google ranking factor might be annoyance, trepidation or frustration, tracking your site’s Core Web Vitals can help your SEO efforts quite a bit.


If you’ve been working in the SEO world for almost any amount of time you’ve probably noticed that Google constantly "advises" to site owners to provide their users with a “great experience” but didn’t really expound on what that might mean.


Well, now you have actual hard data you can track and analyze to ensure that you are, indeed providing users with a positive page experience.


Google Search Console Core Web Vitals


Google recently replaced the Speed Report in Google Search Console with the new Web Core Vitals report. This provides an overview of how all of your web pages perform against the new metrics, categorizing them as either red, for ‘poor URLs’, orange, for ‘URLs need improvement’, and green, for ‘good URLs’.




References

https://www.woorank.com/en/blog/google-core-web-vitals


WebSocket creating simple client and server


Over the past few years, a new type of communication started to emerge on the web and in mobile apps, called websockets. This protocol has been long-awaited and was finally standardized by the IETF in 2011, paving the way for widespread use.


How do Websockets Work?

At its core, a websocket is just a TCP connection that allows for full-duplex communication, meaning either side of the connection can send data to the other, even at the same time.



To establish this connection, the protocol actually initiates the handshake as a normal HTTP request, but then gets 'upgraded' using the upgrade request HTTP header, like this:


GET /ws/chat HTTP/1.1

Host: chat.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: q1PZLMeDL4EwLkw4GGhADm==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 15

Origin: http://example.com



Of the many different websocket libraries for Node.js available to us, I chose to use socket.io throughout this article because it seems to be the most popular and is, in my opinion, the easiest to use. While each library has its own unique API, they also have many similarities since they're all built on top of the same protocol, so hopefully you'll be able to translate the code below to any library you want to use.



Establishing the Connection

In order for a connection to be established between the client and server, the server must do two things:



Hook in to the HTTP server to handle websocket connections

Serve up the socket.io.js client library as a static resource




References:

https://stackabuse.com/node-js-websocket-examples-with-socket-io/

What is Measurement Lab NDT

NDT is a single stream performance measurement of a connection’s capacity for “bulk transport” (as defined in IETF’s RFC 3148. NDT measures “single stream performance” or “bulk transport capacity”. NDT reports upload and download speeds and latency metrics.


Run an NDT Test


Originally developed at Internet2, M-Lab has hosted NDT since our founding in 2009, and helped maintain and develop NDT for most of its history on the M-Lab platform. Over the last decade, there are three primary themes that have driven the evolution of NDT: standard kernel instrumentation, advances in TCP congestion control, and protocols and ports to support more clients


NDT Testing Protocols

As a part of our transition from the web100 version of NDT server to the new platform, M-Lab has named specific protocol versions for the original server and the new one we are now using.


web100 is the protocol refering to data collected by the current NDT server

Relied on the web100 kernel module for tcp statistics

Collected using the original version of NDT server

Used the Reno TCP congestion control algorithm

Retired in November 2019



ndt5 is a new NDT protocol designed to be backward compatible with past NDT clients

Relies on tcp-info for tcp statistics

Collected using M-Lab’s re-written ndt-server, which follows the legacy NDT protocol to support existing NDT clients that use it

Uses the Cubic TCP congestion control algorithm


ndt7 is a new NDT protocol that uses TCP BBR where available, operates on standard HTTP(S) ports (80, 443), and uses TCP_INFO instrumentation for TCP statistics

Relies on tcp-info for tcp statistics

Collected using M-Lab’s re-written ndt-server

Uses the BBR TCP congestion control algorithm, falling back to Cubic when BBR is not available in the client operating system


Data Collected by NDT


When you run NDT, the IP address provided by your Internet Service Provider will be collected along with your measurement results. M-Lab conducts the test and publishes all test results to promote Internet research. NDT does not collect any information about you as an Internet user.




References:

https://www.measurementlab.net/tests/ndt/


What is default timeout of WebSocket


pingTimeout 5000 how many ms without a pong packet to consider the connection closed

pingInterval 25000 how many ms before sending a new ping packet

upgradeTimeout 10000 how many ms before an uncompleted transport upgrade is cancelled


The pingTimeout and pingInterval parameters will impact the delay before a client knows the server is not available anymore. For example, if the underlying TCP connection is not closed properly due to a network issue, a client may have to wait up to pingTimeout + pingInterval ms before getting a disconnect event.


The order of the transports array is important. By default, a long-polling connection is established first, and then upgraded to WebSocket if possible. Using ['websocket'] means there will be no fallback if a WebSocket connection cannot be opened.


const server = require('http').createServer();


const io = require('socket.io')(server, {

  path: '/test',

  serveClient: false,

  // below are engine.IO options

  pingInterval: 10000,

  pingTimeout: 5000,

  cookie: false

});


server.listen(3000);




References:

https://socket.io/docs/server-api/#new-Server-httpServer-options


Cloud run - Best of both worlds

Develop and deploy highly scalable containerized applications on a fully managed serverless platform.

Container to production in seconds

Write code your way by deploying any container that listens for requests or events. Build applications in your favorite language, with your favorite dependencies and tools, and deploy them in seconds.

Fully managed

Cloud Run abstracts away all infrastructure management by automatically scaling up and down from zero almost instantaneously—depending on traffic. Cloud Run only charges you for the exact resources you use.

Enhanced developer experience

Cloud Run makes app development and deployment simpler and faster. And it’s fully integrated with Cloud Code, Cloud Build, Cloud Monitoring, and Cloud Logging for an enhanced end-to-end developer experience.

Below are the key features

Any language, any library, any binary

Use the programming language of your choice, any language or operating system libraries, or even bring your own binaries.

Leverage container workflows and standards

Containers have become a standard to package and deploy code and its dependencies. Cloud Run pairs great with the container ecosystem: Cloud Build, Cloud Code, Artifact Registry, and Docker.


Pay‐per‐use

Only pay when your code is running, billed to the nearest 100 milliseconds.


Monday, October 12, 2020

Siofu file uploader analysis

Thre are multiple control parameters that can be used for file upload especially the chunk sizes 

Based on it, the WebSocket will be configured to send that many size in each packet. 

The chunk size really only tells about the 


42["siofu_chunk",{"id":0}] 26

05:47:08.264

451-["siofu_progress",{"id":0,"size":11242812,"start":10240000,"end":11242812,"content":{"_placeholder":true,"num":0},"base64":false}] 134

05:47:08.268

Binary Message 1.0 MB

05:47:08.275

42["siofu_done",{"id":0}] 25

05:47:08.282

42["siofu_chunk",{"id":0}] 26

05:47:09.900

42["siofu_complete",{"id":0,"success":true,"detail":{}}] 56

05:47:09.901

2 1

05:47:14.785

3 1

05:47:15.084

2 1

05:47:40.087

3 1

05:47:40.511

2 1

05:48:05.514

3 1

05:48:05.812

2 1

05:48:30.817

3 1

05:48:31.302

2 1

05:48:56.304

3 1

05:48:56.700

2 1

05:49:21.704

3 1

05:49:22.004

2 1

05:49:47.006

3 1

05:49:47.333

Data: 2probe, Length: 6, Time: 05:46:50.713

1

2probe



Trying with different chunk sizes, below are the results 


Whatever chunk size that is set before starting the upload, that many bytes of data is sent as WebSocket messages. 

The main drawback of the nam is it does not allow the chunk size to be altered after the upload operation starts.

This restricts us to change the sizes in middle of transfer. Also, the whole concept is based on file storing

This is not helping much as well as the size is constant. 


We need to find some alternative for this. 


References: 

https://www.npmjs.com/package/socketio-file-upload#progress-1

ESLint basics

When building web applications, Linting tools take a crucial role in our development process. Every developer should know what a Linter is, how to install and configure one, and how to use them efficiently making sure that the best code standards are applied to our project.


What is Linting

Linting is the process of evaluating and debugging the source code in the background by analyzing against a set of rules for programmatic and stylistic errors. This allows the developer to find errors before running the code. Rules also enforce best code standards and practices, better code quality, more readable, and easier to maintain.

To ensure good practices and standards several JavaScript Static Analyzer Tools emerged such as:

JSLint: a code quality tool, looks for problems on JavaScript programs.

JSHint: a community-driven tool that detects errors and potential problems in JS code.

ESLint: completely pluggable linter, allows the developer to create their own linting rules.

Flow: using data flow analysis, infers types, and tracks data flows in the code.

Prettier: an opinionated code formatter.

TSLint: extensible static tool analyzer for TypeScript.


ESLint is one of the most used linting tools and there is a reason for it. Highly configurable, it has a huge adoption from the community having hundreds of open-source configurations and plugins. It allows the configuration of several options like coding rules, environments, parser options, extend configurations, and use plugins.


On one hand, ESLint is responsible for checking against programming errors, on the other hand, we have Prettier an opinionated code formatter capable of finding any stylistic errors. It comes with some code style standards and is also easy to configure. It's easy to integrate with ESLint and has Code Editor extensions that can format the code on save!



References:

https://www.imaginarycloud.com/blog/how-to-configure-eslint-prettier-in-react/