Is BIOS read from the BIOS chip or copied into RAM on startup?
Most boards used to have an option in the BIOS to configure this behavior. It was typically called shadowing, and it was usually enabled by default. I don't think many boards bother giving you the option these days and just always shadow. The reason is because RAM is faster than ROM, so it speeds things up to copy it to RAM and run it from there.
Note that the copy isn't done by some magic circuitry, it is just done by the bios itself when it starts executing out of ROM initially, it just copies itself to RAM and then continues executing from there.
This is another case where the received folk wisdom on the subject, as unfortunately exemplified by psusi's answer and indeed part of the question, is stuck in the world as it was around 1991, despite the wealth of technical references available explaining how it is now otherwise.
In the world of the late 1980s, the machine firmware — one of two things called "the BIOS" in the world of the IBM PC compatible — was indeed in a ROM chip on the ISA bus; and CPUs did indeed start executing code at physical address 000FFFF0, a location in "conventional memory" accessed via the real mode pointer F000:FFF0 This world is long gone.
(The world that the author of the WWW page that you pointed to, S. Ebrahim Shubbar, erroneously lives in, despite writing in 2002, is even older. CPUs haven't started with the CS:IP combination FFFF:0000 since the 8086. The 80286 changed this to F000:FFF0. But the 80286 world itself is the highly out of date world of the late 1980s that folk wisdom still circulates.)
Your "BIOS chip" is RAM; and your CPU is not 16-bit.
In modern PCs, the machine firmware is held in non-volatile RAM. The NVRAM chip is connected to the LPC bus (or to a dedicated "firmwware hub" interface), and the LPC/FWH bridge in the "chipset" normally disables write cycles to it. "Flashing" the firmware involves setting chipset registers that enable writes to the NVRAM and then writing to the NVRAM. (In the Intel ICH10, for example, the chipset register bit that allows write cycles through is named BIOSWE, "BIOS Write Enable". There are some additional details that I'll skip over here, but that's the gist of it.)
x86 processors haven't begin execution at location 000FFFF0 since the days of the 80286. 32-bit CPUs start up in what is colloquially known as unreal mode. Even though the initial value of the CS register after reset is F000, the segment descriptor associated with that register initially holds FFFF0000 as its base address. So the physical address that initially corresponds to the the 16:16 CS:IP address F000:FFF0 is in fact, and has been since the days of the 80386, FFFFFFF0.
And that's where the machine firmware is principally mapped into physical address space on 32-bit and 64-bit x86 machines. There's a 128KiB window onto the firmware down in the "conventional memory" area, but the NVRAM holding the machine firmware can be up to 16MiB (although this varies by chipset) on modern PCs and is principally mapped into the 16MiB of physical address space immediately below the 4GiB line — i.e. physical addresses FF000000 to FFFFFFFF. (To use the ICH10 as an example again: How much of this address space is mapped to the NVRAM is controlled by a chipset register known as the FWH_DEC_EN, "Firmware Hub Decode Enable", register. The firmware is coded to re-program the FWH_DEC_EN register according to the size of the actual NVRAM chip that is installed on the mainboard. But the top 512KiB of the NVRAM is always mapped, to physical addresses FFF80000 to FFFFFFF, and cannot be disabled.) The code initially executed by the processor immediately after reset lives in the top 64KiB of this 16MiB address range.
As for BIOS ROM shadowing (which is what it's called — quite why barlop thinks that the CPU is being shadowed is a mystery): Yes, access to NVRAM on the LPC bus or the firmware hub still isn't as fast as access to main system (volatile) RAM. But the reasons that shadowing is important greatly diminished with the advents of operating systems such as OS/2 and Windows NT — again in the late 1980s and early 1990s. Real mode operating systems such as MS-DOS, PC-DOS, DR-DOS and so forth were layered on top of I/O functionality provided by the machine firmware. So the firmware's code and read-only data ended up being accessed a lot at run-time. Protected mode operating systems such as OS/2 and Windows NT rely far less upon firmware-provided services at run-time. So the fact that code executing out of the NVRAM, and read-only data in the same, come to the processor more slowly than when shadowed into system RAM is less of a problem than it used to be.
Moreover, what firmware code and data they do rely upon don't necessarily live in the part of NVRAM mapped to the portion of physical address space, the aforementioned 128KiB "conventional memory" window, that is necessarily even shadowable in the first place. Protected mode firmware services don't all need to live below the 1MiB line in physical address space as real mode firmware services do, and some do not. (And of course it would only be possible to do the same trick with the area of physical address space that they do live in if there's at least 4GiB of system RAM.)
Ironically, a more accurate source for information on this than S. Ebrahim Shubbar writing in 2002 is Phil Croucher's book The BIOS Companion from a year before in 2001. M. Croucher observes that Unices, Linux, Windows NT, and "presumably (95/98)" "derive no benefit from shadowing". It's not necessarily entirely no benefit, but it is comparatively very little with respect to the world of people running MS-DOS, PC-DOS, and DR-DOS in real mode on 16-bit 80286 machines in 1989.